idnits 2.17.1 draft-ietf-ipfc-fibre-channel-04.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-19) 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 48 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 48 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 310 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 149 has weird spacing: '... most of th...' == Line 163 has weird spacing: '...promote inter...' == Line 164 has weird spacing: '...C. This speci...' == Line 166 has weird spacing: '...packets over ...' == (5 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) == Missing Reference: '19' is mentioned on line 1954, but not defined == Unused Reference: '14' is defined on line 1468, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1478, but no explicit reference was found in the text -- 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' -- Duplicate reference: RFC2390, mentioned in '16', was also mentioned in '15'. -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 16 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 July 15, 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 ................................... 5 49 3.1 FC Frame Format ........................................ 5 50 3.2 MTU .................................................... 6 51 3.2.1 IP MTU ........................................... 6 52 3.2.2 Maximally Minimum IPv4 packet .................... 7 53 3.2.3 ARP MTU .......................................... 7 54 3.2.4 FC Payload containing FARP Packet ................ 8 56 3.3 FC Port and Node Network Addresses ..................... 8 57 3.4 FC Payload Format ...................................... 9 59 4. ARP .........................................................10 60 4.1 Address Resolution .................................... 10 61 4.2 ARP Packet Format ...................................... 11 62 4.3 ARP Layer Mapping and Operation ........................ 13 63 4.4 ARP Broadcast in a Point-to-Point Topology ............. 13 64 4.5 ARP Broadcast in a Private Loop Topology ............... 13 65 4.6 ARP Broadcast in a Public Loop Topology ................ 14 66 4.7 ARP Operation in a Fabric Topology ..................... 14 68 5. FARP ....................................................... 15 69 5.1 Scope .................................................. 15 70 5.2 FARP Overview .......................................... 15 71 5.3 FARP Command Format .................................... 16 72 5.4 Match Address Code Points .............................. 19 73 5.5 Responder Flags ........................................ 19 74 5.6 FARP Support Requirements .............................. 20 76 6. Exchange Management ........................................ 21 77 6.1 Exchange Origination ................................... 21 78 6.2 Exchange Termination ................................... 21 80 7. Summary of Supported Features .............................. 21 81 7.1 FC-4 Header ............................................ 21 82 7.2 R_CTL .................................................. 22 83 7.3 F_CTL .................................................. 22 84 7.4 Sequences .............................................. 23 85 7.5 Exchanges .............................................. 24 86 7.6 ARP and InARP ......................................... 25 87 7.7 Extended Link Services (ELS) ........................... 25 88 7.8 Login Parameters ....................................... 26 89 7.8.1 Common Service Parameters - FLOGI ............... 26 90 7.8.2 Common Services Parameters - PLOGI ............... 26 91 7.8.3 Class Service Parameters - PLOGI ................. 26 93 8. Security Considerations .....................................27 95 9. Acknowledgements ........................................... 27 97 10. References ................................................ 27 99 11. Authors' Addresses ........................................ 28 101 Appendix A: Additional Matching Mechanisms in FARP ............ 29 103 Appendix B: InARP ............................................. 32 104 B.1 General Discussion ..................................... 32 105 B.2 InARP Protocol Operation ............................... 32 106 B.3 InARP Packet Format .................................... 32 107 B.4 InARP Support Requirements ............................. 33 109 Appendix C: Some Informal Mechanisms for FC Layer Mappings .....33 110 C.1 Login on cached Mapping Information .................... 33 111 C.2 Login on ARP parsing ................................... 34 112 C.3 Login to Everyone ...................................... 34 113 C.4 Static Table ........................................... 35 115 Appendix D: FC Layer Address Validation........................ 35 116 D.1 General Discussion ..................................... 35 117 D.2 FC Layer Address Validation in a Point-to-Point Topology 35 118 D.3 FC Layer Address Validation in a Private Loop Topology . 36 119 D.4 FC Layer Address Validation in a Public Loop Topology .. 36 120 D.5 FC layer Address Validation in a Fabric Topology ....... 36 122 Appendix E: Fibre channel Overview ............................ 37 123 E.1 Brief Tutorial ......................................... 37 124 E.2 Exchange, Information Unit, Sequence, and Frame ........ 38 125 E.3 Fibre Channel Header Fields ............................ 38 126 E.4 Code Points for FC Frame ............................... 41 127 E.4.1 With IP and ARP Packet .......................... 41 128 E.4.2 With FARP Command ............................... 43 130 Appendix F: Fibre Channel Protocol Considerations.............. 45 131 F.1 Reliability in Class 3 ................................. 45 132 F.2 Continuously Increasing SEQ_CNT ........................ 45 134 Appendix G: Acronyms and Glossary of FC Terms ................. 46 136 1. Introduction 138 Fibre Channel is a gigabit speed networking technology primarily used 139 for Storage Area Networking (SAN). FC is standardized under American 140 National Standard for Information Systems of the National Committee 141 for Information Technology Standards (NCITS) and has specified a 142 number of documents describing its protocols, operations, and 143 services. 145 Need: 147 Currently, Fibre Channel is predominantly used for communication 148 between storage devices and servers using the SCSI protocol, with 149 most of the servers still communicating with each other over LANs. 150 Although, there exists a Fibre Channel Standard [3] that has 151 architecturally defined support for IP encapsulation and address 152 resolution, it is inadequately specified. ([3] prohibits broadcasts, 153 thus loops are not covered; [10] has no support for Class 3). 155 This has lead to a nonstandard way of using IP over FC in the past. 156 Once such a standard method is completely specified, servers can 157 directly communicate with each other using IP over FC, possibly 158 boosting performance in Server host-to-host communications. This 159 technique will be especially useful in a Clustering Application. 161 Objective and Scope: 163 The major objective of this specification is to promote inter- 164 operable implementations of IPv4 over FC. This specification 165 describes a method for encapsulating IPv4 and Address Resolution 166 Protocol (ARP) packets over FC. This specification accommodates any 167 FC topology (loop, fabric, or point-to-point) and any FC class of 168 service (1, 2 or 3). This specification also describes a FC Address 169 Resolution Protocol(FARP) for associating MAC addresses to FC Port 170 identifiers. 172 A secondary objective of this specification is to describe other 173 optional FARP mechanisms that directly build IPv4 address and FC Port 174 Identifier (Port_ID) associations. Inverse ARP (InARP) is another 175 optional mechanism that is described which allows learning the IP 176 address of a remote node given its MAC address and Port_ID. 178 Organization: 180 Section 2 states the problem that is solved in this specification. 181 Section 3 describes the techniques used for encapsulating IP and ARP 182 packets in a FC sequence. Section 4 discusses the ARP protocol(IP 183 address to MAC address). Section 5 discusses the FARP protocol used 184 in FC Layer mappings (MAC address to Port_ID). Section 6 describes 185 the "Exchange" Management in FC. Section 7 is a summary section and 186 provides a quick reference to FC header settings, FC Link Service 187 Commands, supported features in ARP, FARP, InARP, FC Sequences, FC 188 Exchanges, and FC Login Parameters. Section 8 discusses any security 189 considerations. Section 9 acknowledges the technical contributors of 190 this document. Section 10 provides a list of references, and Section 191 11 provides the authors' addresses. 193 Appendix A discusses other FARP mechanisms that are optional. 194 Appendix B discusses the Inverse ARP protocol(MAC address to IP 195 address) as an alternate and optional way to build MAC and IP address 196 associations. Appendix C lists some informal mechanisms for FC Layer 197 Mappings. Appendix D provides a discussion on validation of the FC- 198 layer mappings for the different FC topologies. Appendix E provides 199 a brief overview of the FC Protocols and Networks. Appendix F 200 addresses reliability in Class 3 and Sequence Count FC Protocol 201 issues. Appendix G provides a list of acronyms and a glossary of FC 202 Terms used in this specification. 204 2. Problem Statement 206 This draft addresses two problems: 208 - A format definition and encapsulation mechanism for IPv4 209 and ARP packets over FC 210 - Mechanisms for Address Resolution 212 As noted earlier, the existing FC Standards [3], [10] are inadequate 213 to solve these problem. A solution to both problems was first 214 proposed by the Fibre Channel Association (FCA)[1]. FCA is a industry 215 consortium of FC vendor companies and not a standards body. This 216 draft specification is based on the proposed solution in [1] and 217 builds on it. 219 Address Resolution is concerned with resolving IP addresses to MAC 220 address and MAC addresses to FC Port Identifiers (Port_ID). ARP 221 provides a solution to the first resolution problem and FARP the 222 second. 224 An optional FARP mechanism resolves IP address directly to FC 225 Port_IDs. This is useful in some upper layer applications. 227 InARP is another optional mechanism that resolves MAC and Port_IDs to 228 an IP address. InARP is useful when a node after performing a PLOGI 229 with a remote node knows its WW_PN and Port_ID, but not its IP 230 address. 232 3. IP and ARP Encapsulation 234 3.1 FC Frame Format 236 All FC frames have a standard format much like LAN 802.x protocols. 237 (See Appendix E and F). However, the exact size of each frame varies 238 depending on the sizes of the variable fields. The size of the 239 variable fields ranges from 0 to 2111 bytes as shown in the FC frame 240 structure in Fig. 1. 242 +------+--------+-----------+----//-------+------+------+ 243 | SOF |Frame |Optional | Payload | CRC | EOF | 244 | (4B) |Header |Header | | (4B) | (4B) | 245 | |(24B) |<----------------------->| | | 246 | | | (0-2112B) | | | 247 +------+--------+-----------+----//-------+------+------+ 249 Fig. 1 FC Frame Format 251 The Start of Frame (SOF) and End of Frame (EOF) are both 4 bytes long 252 and act as frame delimiters. 254 The CRC is 4 bytes long and uses the same 32-bit polynomial used in 255 FDDI and is specified in ANSI X3.139 Fiber Distributed Data 256 Interface. 258 The Frame Header is 24 bytes long and has several fields associated 259 with identification and control of the payload. Some of the values 260 and options for the fields that are relevant to the IP and ARP 261 payloads are discussed in Section 7. 263 A FC Optional Header allows up to 4 optional header fields: 265 - An Expiration Security Header (16 bytes) 266 - Network (16 bytes) 267 - Association (32 bytes) 268 - Device (up to 64 bytes). 270 The IP and ARP FC Sequences shall carry only the Network_Header 271 optional header field which is 16 bytes long. Other types of optional 272 headers are prohibited. The role of the Network_Header in the IP and 273 ARP payload encapsulation is described below. 275 An application level payload such as IP in FC is called a Information 276 Unit at the FC-4 Level. Lower FC levels map this to what is called as 277 a FC Sequence. (See Appendix E.2 for a description of Sequences and 278 Information Units.) Typically, a Sequence consists of more than one 279 frame. Larger user data is segmented and reassembled using two 280 methods: Sequence Count and Relative Offset [18]. With the use of 281 Sequence Count, data blocks are sent using frames with increasing 282 sequence counts (modulo 65536) and it is quite straightforward to 283 detect the first frame that contains the Network Header. When 284 Relative Offset is used, as frames arrive, some computation is 285 required to detect the first frame that contains the Network Header. 286 Sequence Count and Relative Offset field control information is 287 carried in the FC Header and described in Appendix E. 289 In FC, the physical temporal ordering of the frames as it arrives at 290 a destination can be different from the order sent as a result of 291 traversing through a FC Network. 293 When IP forms the FC payload then only the first frame of the logical 294 Sequence shall include the FC Network_Header. Fig. 2 shows the 295 logical First Frame and logical subsequent frames. Since frames may 296 arrive out of order, detection of the first frame of the logical FC 297 Sequence is necessary. 299 ARP packets map to a single frame FC Sequence and shall always carry 300 the FC Network Header. 302 First Frame of a Logical FC Sequence 303 ---+------------+---------------------------+----------//----------+--- 304 | FC Header | FC Network Header | FC Sequence Data | 305 ---+------------+---------------------------+---------//-----------+--- 307 Subsequent Frames of a Logical FC Sequence 308 --+-----------+--------------//------------+-- 309 | FC Header | Additional FC Sequence Data | 310 --+-----------+-------------//-------------+-- 312 Fig. 2 FC Network Header in a Frame Sequence 314 The SOF, CRC, EOF control fields of the FC frame and other optional 315 headers have been omitted in the figure for clarity. 317 3.2 MTU 319 3.2.1 IP MTU 321 An FC Information Unit specific to each protocol data such as IP is 322 defined in FC-4. This defines the upper bound on the size of the 323 information that can be transported. 325 Each IP or ARP Packet is mapped to a single FC Information Unit, 326 which is in turn mapped to a single FC Sequence. Therefore there 327 shall be a one-to-one mapping between an IP or ARP packet and a FC 328 Sequence. 330 Fibre Channel limits the size of a single Information Unit to 2^32-1, 331 which is very large [2]. However, since the Maximum Transmission 332 Unit (MTU) size of an IPv4 packet does not exceed 65,536 bytes, the 333 resulting FC Payload size is far below its maximum limit. The FC 334 Payload includes the FC Network Header (16 bytes), the LLC/SNAP 335 Header (8 bytes), and the IP packet. 337 IPv4 Packet definition includes the IP Payload and IP Headers - both 338 fixed and optional. The corresponding FC Payload includes the FC 339 Network Header, the LLC/SNAP Header, and the IPv4 Packet. 341 As noted above, the greatest length allowed for an IPv4 Packet 342 including any optional headers and independent of this standard is 343 65,536 bytes. However, limiting the IP MTU size to 65,280 bytes helps 344 in buffer resource allocation at N_Ports and also allows for up to 345 255 bytes of overhead. Since the FC Network Header requires 16 bytes 346 and the IEEE 802.2 LLC/SNAP header requires 8 bytes, it leaves 232 347 bytes for future use. 349 All implementations shall restrict the IP MTU size to 65,280 bytes 350 and the corresponding FC MTU size to 65536 bytes. 352 3.2.2 Maximally Minimum IPv4 Packet 354 In order to avoid fragmentation in FC, it is useful to specify a 355 minimum size FC Payload size. This is relevant when a minimum size 356 IP Packet with a fixed size IP Header and a zero byte IP Payload is 357 carried in the FC Payload. More importantly is the case when, the FC 358 Payload carries a maximally minimum size IP Packet, which is defined 359 as an IP packet with a zero byte payload, a fixed size IP Header (20 360 bytes), and the maximum size optional IP Header (48 bytes) [19]. 362 All implementations shall support a maximally minimum sized FC 363 Payload of 92 bytes, which is required to support 68 bytes of a 364 maximally minimum size IP Packet, 16 bytes of the FC Network Header, 365 and 8 bytes of the LLC/SNAP Header. 367 3.2.3 ARP MTU 369 The ARP packet has a fixed size of 28 bytes. All implementations 370 shall support a FC Payload size of 52 bytes, which is required to 371 support 28 bytes of an ARP Packet, 16 bytes of the FC Network Header, 372 and 8 bytes of the LLC/SNAP Header. Note that the minimum MTU 373 requirement for ARP is covered by the minimum MTU requirement for IP 374 but it is mentioned here for completeness. 376 The InARP packet is identical in size to the ARP and the same MTU 377 requirements apply. 379 3.2.4 FC Payload containing FARP Packet 381 The FARP Command is a FC Extended Link Service (ELS) command and maps 382 directly to a FC payload without the LLC/SNAP or the FC Network 383 Header. The FARP Command has a fixed size of 76 bytes. Because FARP 384 operates purely in the FC space, it places no special MTU 385 requirements in this specification. 387 3.3 FC Port and Node Network Addresses 389 FC devices are identified by Nodes and their Ports. A Node is a 390 collection of one or more Ports identified by a unique nonvolatile 391 64-bit World Wide Node name (WW_NN). Each Port in a node, is 392 identified with a unique nonvolatile 64-bit World Wide Port name 393 (WW_PN), and a volatile Port Identifier (Port_ID). 395 Port_IDs are 24-bits long. A FC frame header carries a Source Port_ID 396 (S_ID) and the Destination Port_ID (D_ID). The Port_ID of a given 397 port is volatile. (The mechanism(s) by which a Port_ID may change in 398 a FC topology is outside the scope of this document. See Appendix D). 400 The FC Network Header is generally optional in FC Standards, but 401 mandatory in this specification. FC Network Headers carry source and 402 destination WW_PNs. A WW_PN consists of a 60-bit Network Address and 403 a upper 4-bit Network Address Authority (NAA) field as shown in Fig. 404 3. The 4-bit NAA field is used to distinguish between the various 405 name registration authorities used to define the Network Address [2]. 407 In this specification, both the Source and Destination 4-bit NAA 408 identifiers shall be set to binary '0001' indicating that an IEEE 409 48-bit MAC address is contained the lower 48 bits of the network 410 address fields. The high order 12 bits in the network address fields 411 shall be set to 0x0000. This NAA field value allows FC networks to be 412 bridged with other FC networks or traditional LANs. 414 +--------+---------------------------------------+ 415 | D_NAA |Network_Dest_Address (High-order bits) | 416 |(4 bits)| (28 bits) | 417 +--------+---------------------------------------+ 418 | Network_Dest_Address (Low-order bits) | 419 | (32 bits) | 420 +--------+---------------------------------------+ 421 | S_NAA |Network_Source_Address(High-order bits)| 422 |(4 bits)| (28 bits) | 423 +--------+---------------------------------------+ 424 | Network_Source_Address (Low-order bit) | 425 | (32 bits) | 426 +--------+---------------------------------------+ 428 Fig. 3 Format of the Network Header Field 430 3.4 FC Payload Format 432 FC Payload with IP: 434 The payload of a FC sequence carrying an IP and ARP packet shall use 435 the formats shown in Fig. 4 and 5 respectively. Both formats use the 436 8-byte LLC/SNAP header. 438 +-----------------+-----------+------------+-------------//----------+ 439 | LLC/SNAP Header | IP Header | Opt. IPHdr.| IP Data | 440 | (8 bytes) | (20 bytes)| (48 bytes | (65280 -IP Header | 441 | | | Max) | - Opt. Hdr.) bytes | 442 +-----------------+-----------+------------+-------------//----------+ 444 Fig. 4 Format of FC Sequence Payload carrying IP 446 FC Payload with ARP: 448 As noted earlier, FC frames belonging to the same Sequence may be 449 delivered out of order over a Fabric. If the Relative Offset method 450 is used to identify FC payload fragments, then the IP Header must 451 appear in the frame that has a relative offset of 0. 453 +-----------------+-------------------+ 454 | LLC/SNAP Header | ARP Packet | 455 | (8 bytes) | (28 bytes) | 456 +-----------------+-------------------+ 458 Fig. 5 Format of FC Sequence Payload carrying ARP 460 FC payload with FARP: 462 FARP Protocol commands are directly mapped to a FC payload and do not 463 carry the LLC/SNAP or FC Network Header. FARP commands are 76 bytes 464 long. 466 LLC: 468 A Logical Link Control (LLC) field along with a Sub Network Access 469 Protocol (SNAP) field is a method used to identify routed and bridged 470 non-OSI protocol PDUs and is defined by IEEE 802.2 and applied to IP 471 in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless 472 mode), the LLC header is 3-bytes long and consists of a 1-byte 473 Destination Service Access Point (DSAP)field, a 1-byte Source Service 474 Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 475 6. 477 +----------+----------+----------+ 478 | DSAP | SSAP | CTRL | 479 | (1 byte) | (1 byte | (1 byte) | 480 +----------+----------+----------+ 482 Fig. 6 LLC Format 484 The LLC's DSAP and SSAP values of 0xAA indicate that an IEEE 802.2 485 SNAP header follows. The LLC's CTRL value equal to 0x03 specifies an 486 Unnumbered Information Command PDU. In this specification the LLC 487 Header value shall be set to 0xAA-AA-03. Other values of DSAP/SSAP 488 indicate support for other protocols but are prohibited in this 489 specification. 491 SNAP: 493 The SNAP Header is 5 bytes long and consists of a 3-byte 494 Organizationally Unique Identifier (OUI) field and a 2-byte Protocol 495 Identifier (PID) as shown in Fig. 7 497 +------+------+-------+------+------+ 498 | OUI | PID | 499 | ( 3 bytes) | (2 bytes) | 500 +------+------+-------+------+------+ 502 Fig. 7 SNAP Format 504 SNAP was invented to "encapsulate" LAN frames within the payload. 505 The SNAP OUI value 0x00-00-00 specifies that the PID is an EtherType 506 (i.e., routed non-OSI protocol). 508 The SNAP OUI value of 0x00-80-C2 indicates Bridged Protocols. 510 With the OUI value set to 0x00-00-00, the SNAP PID value of 0x08-00 511 indicates IP and a PID value of 0x08-06 indicates ARP (or InARP). 513 The complete LLC/SNAP Header is shown in Fig. 8. 515 +----------+----------+----------+-------+-------+-------+-------+------+ 516 | DSAP | SSAP | CTRL | OUI | PID | 517 | (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes | 518 +----------+----------+----------+-------+-------+-------+-------+------+ 520 Fig. 8 LLC/SNAP Header 522 4. ARP 524 4.1 Address Resolution 526 Address Resolution in this specification is concerned with 527 associating IP addresses with FC Port addresses. As described 528 earlier, FC device ports have two types of addresses: 530 - a non-volatile unique 64-bit address called World Wide Port_Name 531 (WW_PN) - a volatile 24-bit address called a Port_ID 533 The Address Resolution mechanism therefore will need two levels of 534 mapping: 536 1. A mapping from the IP address to the WW_PN (i.e., IEEE 537 48-bit MAC address) 539 2. A mapping from the WW_PN to the Port_ID (see Appendix F for a 540 definition of Port_ID) 542 The address resolution problem is compounded by the fact that the 543 Port_ID is volatile and the second mapping has to be valid before 544 use. Moreover, this validation process can be different depending on 545 the FC network topology used. Appendix D provides a discussion on 546 validation for the different FC topologies. 548 Architecturally, the first level of mapping and control operation is 549 handled by the Address Resolution Protocol (ARP), and the second 550 level by the FC Address Resolution Protocol (FARP). FARP is described 551 in Section 5. 553 Another optional mechanism in FARP which directly maps IP addresses 554 to Port_IDs is described in Appendix A. 556 The Inverse Address Resolution Protocol (InARP) is yet another method 557 that resolves MAC and Port_IDs to IP addresses. InARP is described 558 Appendix B. 560 4.2 ARP Packet Format 562 The Address Resolution Protocol (ARP) was designed to be a general 563 purpose protocol, and to work with many network technologies, and 564 with many upper layer protocols [9]. Fig 9 shows the ARP packet 565 format where the upper layer protocol uses a 4 octet IP address and 566 the network technology uses six-octet MAC address. 568 The ARP consists of two packet types - Request and Reply - and the 569 ARP Packet is 28 bytes long in this application. The ARP Packet 570 fields are common to both ARP Requests and ARP Replies. The format of 571 the encapsulated ARP packet is based on [9]. 573 The LLC/SNAP encapsulated ARP Request Packet is mapped to a FC 574 broadcast sequence and the exact mechanism used to broadcast a FC 575 Sequence depends on the FC topology. This is discussed later in this 576 section. Compliant ARP Request broadcasts shall include Network 577 Headers. 579 The LLC/SNAP encapsulated ARP Reply Packet is mapped to a FC 580 Sequence. Compliant ARP Replys shall include Network Headers. 582 Note that in all discussions to follow, the WW_PN and the 48-bit MAC 583 address conceptually mean the same thing. 585 The 'HW Type' field shall be set to 0x00-01. 587 Technically, the correct HW Type value should be set to 0x00-06 588 according to RFC 1700 indicating IEEE 802 networks. However, as a 589 practical matter a HW Type value of 0x00-06 is known to cause 590 rejections from some Ethernet end stations when FC is bridged to 591 Ethernet. Translational bridges are normally expected to change this 592 field from Type 6 to 1 and vice versa under these configurations, but 593 many do not. It is because of this reason the Type Code is set to 1 594 rather than 6. However, both HW Type values of 0x00-01 and 0x00-06 595 shall be accepted. 597 The 'Protocol' field shall be set to 0x08-00 indicating IP protocol. 599 The 'HW Addr Length' field shall be set to 0x06 indicating 6 bytes of 600 HW address. 602 The 'Protocol Addr Length' field shall be set to 0x04 indicating 4 603 bytes of IPv4 address. 605 The 'Operation' Code field shall be set as follows: 607 0x00-01 for ARP Request 608 0x00-02 for ARP Reply 610 The 'HW Addr of Sender' field shall be the 6 byte IEEE MAC address of 611 the sender. It is either the Requester (ARP Request) or the Responder 612 (ARP Reply) address. 614 The 'Protocol Addr of Sender' field shall be the 4 byte IP address of 615 the Requester (ARP Request) or that of the Responder (ARP Reply). 617 The 'HW Addr of Target' field shall be set to zero during an ARP 618 Request and to the 6 byte MAC address of the Requester (ARP Request) 619 in an ARP Reply. 621 The 'Protocol Addr of Target' field shall be set to the 4-byte IP 622 address of the Responder (ARP Reply) in a ARP Request, and to the 623 4-byte IP address of the Requester (ARP Request) in an ARP Reply. 625 +-------------------------+ 626 | HW Type | 2 bytes 627 +-------------------------+ 628 | Protocol | 2 bytes 629 +-------------------------+ 630 | HW Addr Length | 1 byte 631 +-------------------------+ 632 | Protocol Addr Length | 1 byte 633 +-------------------------+ 634 | Op Code | 2 bytes 635 +-------------------------+ 636 | HW Addr of Sender | 6 bytes 637 +-------------------------+ 638 | Protocol Addr of Sender | 4 bytes 639 +-------------------------+ 640 | HW Addr of Target | 6 bytes 641 +-------------------------+ 642 | Protocol Addr of Target | 4 bytes 643 +-------------------------+ 644 Total 28 bytes 645 Fig. 9 ARP Packet Format 647 4.3 ARP Layer Mapping and Operation 649 Whenever a FC port wishes to send IP data to another FC port, then 650 the following steps are taken: 652 1. The source port shall consult its local mapping tables to 653 determine the . 655 2. If such a mapping is found, then the source shall send the IP 656 data to the port whose WW_PN address was found in the table. 658 3. If such a mapping is not found, then the source shall send an 659 ARP Request broadcast to its connected FC network in 660 anticipation of getting a reply from the correct destination 661 along with its WW_PN. 663 4. When an ARP Request broadcast frame is received by a node with 664 the matching IP address, then it shall generate an ARP Reply. 665 Since the ARP Reply must be addressed to a specific 666 destination Port_ID, the FC layer mapping between the MAC 667 address and Port_ID (of the ARP Request orginator) must be 668 valid before the reply is sent. 670 5. If no node has the matching IP address, it results in a silent 671 behavior. 673 4.4 ARP Broadcast in a Point-to-Point Topology 675 The ARP Request (Broadcast) and Reply mechanism described above 676 still apply, although there is only one node that receives the ARP 677 Request. 679 4.5 ARP Broadcast in a Private Loop Topology 681 In a private loop, the ARP Request broadcast frame is sent using 682 the broadcast method specified in the FC-AL [7]standard. 684 1. The source port shall first send an Open Broadcast 685 Replicate primitive (OPN(fr))Signal forcing all the ports in 686 the loop (except itself), to replicate the frames that they 687 receive while examining the frame header's Destination_ID 688 field. 690 2. The source port shall remove this OPN(fr) signal when it 691 returns to it. 693 3. The loop is now ready to receive the ARP broadcast. 694 The source now sends the ARP Request as a single-frame 695 broadcast Sequence in a Class 3 frame with the following 696 FC Header D_ID field and F_CTL bits setting: 698 Destination ID : D_ID = 0xFF-FF-FF 700 Sequence Initiative : SI=0 701 Last Sequence : LS=1 703 End Sequence : ES=1. 705 4. A compliant ARP broadcast sequence frame shall include the 706 Network Header with destination MAC address set to 707 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001' 709 5. The destination port recognizing its IP address in the ARP 710 Request packet shall respond with an ARP Reply. 712 4.6 ARP Broadcast in a Public Loop Topology 714 The following steps will be followed when a port is configured in a 715 public loop: 717 1. A public loop device attached to a fabric through a FL_Port 718 shall not use the OPN(fr) signal primitive. Rather, it shall 719 send the broadcast sequence to the FL_Port at AL_PA = 0x00. 721 2. A FC Fabric shall propagate the broadcast to all other ports 722 including the FL_Port which the broadcast arrived on. This 723 includes all F_Ports, and other FL_Ports. 725 3. On each FL_Port, the fabric shall first propagate the 726 broadcast by first using the primitive signal OPNfr, in order 727 to prepare the loop to receive the broadcast sequence. 729 4. A broadcast sequence is now sent on all ports (all FL_ports, 730 F_Ports) in Class 3 frame with: 732 Destination ID : D_ID = 0xFF-FF-FF 734 Sequence Initiative : SI=0 736 Last Sequence : LS=1 738 End Sequence : ES=1. 740 5. A compliant ARP broadcast sequence frame shall include the 741 Network Header with destination MAC address set to 742 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001' 744 6. The destination port recognizing its IP address in the ARP 745 Request packet shall respond with an ARP Reply. 747 4.7 ARP Operation in a Fabric Topology 749 1. Nodes directly attached to fabric do not require the OPN(fr) 750 primitive signal. 752 2. A broadcast sequence is now sent on all ports (all FL_ports, 753 F_Ports) in Class 3 frame with: 755 Destination ID : D_ID = 0xFF-FF-FF 757 Sequence Initiative : SI=0 759 Last Sequence : LS=1 761 End Sequence : ES=1. 763 3. A compliant ARP broadcast sequence frame shall include the 764 Network Header with destination MAC address set to 765 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001' 767 4. The destination port recognizing its IP address in 768 the ARP packet shall respond with an ARP Reply. 770 5. FARP 772 5.1 Scope 774 FC Layer Mapping between the WW_PN and the Port_ID is independent of 775 the ARP mechanism and is more closely associated with the details of 776 the FC protocols. Name Server and FARP are two formal mechanisms that 777 can be used to create and maintain WW_PN to Port_ID tables. 779 The FC Address Resolution Protocol (FARP) is a method using Extended 780 Link Service (ELS) commands that resolves mappings. 781 The WW_PN to Port_ID address resolution using FARP is especially 782 useful for instance when the Login table entries at a node expire and 783 a Name Server is not available. It is outside the scope of this 784 document to describe Name Server. (See [4].) 786 Additional address matching mechanisms that resolve 787 and mapping have been added to FARP. These 788 additional mechanisms are optional and described in Appendix A. 789 Direct IP address to Port_ID mapping may be desirable in some 790 applications where there is no visibility of the MAC address. 792 Other less formal FC Layer Mapping mechanisms are described in 793 Appendix C. 795 Since Port_IDs are volatile, all mapped Port_IDs at all times have 796 to be valid before use. There are many events that can invalidate 797 this mapping. Appendix D discusses conditions when such a validation 798 is required. 800 5.2 FARP Overview 802 The FARP protocol uses two ELS commands - FARP-REQ and FARP-REPLY. 804 Note: In the following discussion 'Requester' means the node 805 issuing the FARP-REQ ELS message; 'Responder' means the 806 node replying to the request by sending the FARP-REPLY 807 command. 809 The FARP-REQ ELS Broadcast Request command is used to retrieve a 810 specific node's current Port_ID given its unique WW_PN. This Port_ID 811 is sent in a FARP-REPLY unicast command. 813 The FARP-REQ may indicate that the Responder: 815 - Perform only a Login with it (Requester) 817 - Send only a FARP-REPLY 819 - Perform a Login and send a FARP-REPLY. 821 No sequence initiative is transferred with the FARP-REQ and therefore 822 no Reply (ACCEPT or REJECT) follows this command. 824 Since a Sequence Initiative is transferred with the FARP-REPLY, 825 either a ACCEPT or REJECT follows this command as a response. 827 Reception of a FARP-REQ may require a higher level entity at the 828 responding node to send a FARP-REPLY or perform a Port Login. 830 You do not have to be logged in to issue a FARP Request. Also, you do 831 not have to be logged in to the FARP Requester to issue a FARP-REPLY. 833 The FARP Protocol Steps: 835 FARP-REQ (ELS broadcast) Request Sequence 837 (No Reply Sequence) 839 FARP-REPLY (ELS command) Sequence 841 Accept/Reject Reply Sequence 843 The FARP Protocol Format [2]: 845 FT_1 847 The FARP Protocol Addressing: 849 - In a FARP-REQ, the S_ID in the FC Header designates the 850 Requester's Port ID. The D_ID in the FC Header is the 851 broadcast identifier, 0xFF-FF-FF. 853 - In a FARP-REPLY, the S_ID in the FC Header designates the 854 Responder's Port_ID. The D_ID in the FC Header is the 855 Requester's Port_ID. 857 5.3 FARP Command Format 859 FARP-REQ and FARP REPLY commands have identical formats and fields 860 but use different command codes. See tables below. 862 +---------------------------------------------------------------------+ 863 | FARP-REQ Command | 864 +-------------------------------------+---------+---------------------+ 865 | Field | Size | Remarks | 866 | | (Bytes) | | 867 +-------------------------------------+---------+---------------------+ 868 | 0x54-00-00-00 | 4 | Request Command Code| 869 +-------------------------------------+---------+---------------------+ 870 | Match Address Code Points | 1 | Indicates Address | 871 | | | Matching Mechanism | 872 +-------------------------------------+---------+---------------------+ 873 | Port_ID of Requester | 3 | Supplied by | 874 | | | Requester = | 875 | | | S_ID in FC Header | 876 +-------------------------------------+---------+---------------------+ 877 | Responder Flags | 1 | Response Action to | 878 | | | be taken | 879 +-------------------------------------+---------+---------------------+ 880 | Port_ID of Responder | 3 | Set to 0x00-00-00 | 881 +-------------------------------------+---------+---------------------+ 882 | WW_PN of Requester | 8 |Supplied by Requester| 883 +-------------------------------------+---------+---------------------+ 884 | WW_NN of Requester | 8 |OPTIONAL; | 885 | | |See Appendix A | 886 +-------------------------------------+---------+---------------------+ 887 | WW_PN of Responder | 8 |Supplied by Requester| 888 +-------------------------------------+---------+---------------------+ 889 | WW_NN of Responder | 8 |OPTIONAL; see App. A | 890 +-------------------------------------+---------+---------------------+ 891 | IP Address of Requester | 16 |OPTIONAL; see App. A | 892 +-------------------------------------+---------+---------------------+ 893 | IP Address of Responder | 16 |OPTIONAL; see App. A | 894 +-------------------------------------+---------+---------------------+ 896 Following is a brief description of the address fields in the FARP 897 Commands. 899 Port_ID of Requester: 901 It is the 24-bit Port_ID used in the S_ID field of the FC Header of a 902 FARP-REQ. It is supplied by the Requester in FARP-REQ. It is 903 retained in FARP-REPLY. 905 Port_ID of Responder: 907 It is the 24-bit Port_ID used in the S_ID field of the FC Header of a 908 FARP-REPLY. It is set to 0x00-00-00 in a FARP-REQ. It is supplied by 909 the Responder in a FARP-REPLY. 911 WW_PN: 913 This address field is used with the b'001' (MATCH_WW_PN) Match 914 Address Code Point. See Match Address Code Point Table below. The 915 Requester supplies the unique 8-byte WW_PN of the Requester and the 916 Responder. It is retained in a FARP-REPLY. 918 WW_NN: 920 The WW_NN address field is used with Match Address Code Points 921 b'010', b'011, and b'111', which are all optional. Its usage is fully 922 described in Appendix A. When the WW_NN field is not used it shall be 923 either set to '0' or a valid non-zero address. 925 IPv4: 927 The IPv4 address field is used with the MATCH_IPv4 Match Address Code 928 Points b'100', b'101', and b'111', which are all optional. Its usage 929 is fully described in Appendix A. When the IP Address field is not 930 used it shall be either set to '0' or a valid IP address. A valid IP 931 address consists of the 32-bit IPv4 Address with the upper 96 bits 932 set to '0'. 934 +---------------------------------------------------------------------+ 935 | FARP-REPLY Command | 936 +-------------------------------------+---------+---------------------+ 937 | Field | Size | Remarks | 938 | | (Bytes) | | 939 +-------------------------------------+---------+---------------------+ 940 | 0x55-00-00-00 | 4 | Reply Command Code | 941 +-------------------------------------+---------+---------------------+ 942 | Match Address Code Points | 1 | Not Used and | 943 | | | Unchanged from the | 944 | | | FARP-REQ | 945 +-------------------------------------+---------+---------------------+ 946 | Port_ID of Requester | 3 | Extracted from | 947 | | | FARP-REQ | 948 +-------------------------------------+---------+---------------------+ 949 | Responder Flags | 1 | Not Used and | 950 | | | Unchanged from the | 951 | | | FARP-REQ | 952 +-------------------------------------+---------+---------------------+ 953 | Port_ID of Responder | 3 | Supplied by | 954 | | | Responder = | 955 | | | S_ID in FC Header | 956 +-------------------------------------+---------+---------------------+ 957 |WW_PN of Requester | 8 |Supplied by Requester| 958 +-------------------------------------+---------+---------------------+ 959 |WW_NN of Requester | 8 |OPTIONAL; see App. A | 960 +-------------------------------------+---------+---------------------+ 961 |WW_PN of Responder | 8 |Supplied by Requester| 962 +-------------------------------------+---------+---------------------+ 963 |WW_NN of Responder | 8 |OPTIONAL; see App. A | 964 +-------------------------------------+---------+---------------------+ 965 |IP Add. of Requester | 16 |OPTIONAL; see App. A | 966 +-------------------------------------+---------+---------------------+ 967 |IP Address of Responder | 16 |OPTIONAL; see App. A | 968 +-------------------------------------+---------+---------------------+ 970 5.4 Match Address Code Points 972 For each receipt of the FARP-REQ Broadcast ELS, the recipients match 973 one or more addresses based on the encoded bits of the "FARP Match 974 Address Code Points" field shown in the table below. FARP operation 975 with the Match Address Code Point equal to b'001' is described in 976 this section. Other code points are optional and discussed in 977 Appendix A. The upper 5 bits of the Match Address Code Point byte are 978 unused their use not defined. 980 When a node receives a FARP-REQ with Code Point b'001', it checks its 981 WW_PN against the one set in 'WW_PN of Responder' field of the FARP- 982 REQ command. If there is a match, then the node issues a response 983 according to the action indicated by the FARP Responder Flag. See 984 table below. 986 WW_NN and IPv4 address fields are not used with the b'001' Code Point 987 operation. They shall be set to '0' or a valid address either by the 988 Requester or the Requester and the Responder. 990 +------------------------------------------------------------------+ 991 | Match Address Code Points | 992 +------------------------------------------------------------------+ 993 | LSBits | Bit name | Action | 994 +-----------+--------------------+---------------------------------+ 995 | 000 | Reserved | | 996 +-----------+--------------------+---------------------------------+ 997 | 001 | MATCH_WW_PN | If 'WW_PN of Responder' = | 998 | | | Node's WW_PN then respond | 999 +-----------+--------------------+---------------------------------+ 1000 | 010 | MATCH_WW_NN | OPTIONAL; see Appendix A | 1001 +-----------+--------------------+---------------------------------+ 1002 | 011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A | 1003 +-----------+--------------------+---------------------------------+ 1004 | 100 | MATCH_IPv4 | OPTIONAL; see Appendix A | 1005 +-----------+--------------------+---------------------------------+ 1006 | 101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A | 1007 +-----------+--------------------+---------------------------------+ 1008 | 110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A | 1009 +-----------+--------------------+---------------------------------+ 1010 | 111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A | 1011 +-----------+--------------------+---------------------------------+ 1013 5.5 Responder Flags 1015 The Responder Flags define what Responder action to take if the 1016 result of the Match Address Code Points is successful. 'Responder 1017 Flags' is an 8-bit field (bits 0-7) and is defined in the table 1018 below. This field is used only in a FARP-REQ. This field is retained 1019 unchanged in a FARP-REPLY. If no bits are set, the Responder will 1020 take no action. 1022 +----------+-------------------------------------------------------+ 1023 | | FARP Responder Flag | 1024 +----------+----------------+--------------------------------------+ 1025 | Bit | Bit Name | Action | 1026 | Position | | | 1027 +----------+----------------+--------------------------------------+ 1028 | 0 | INIT_P_LOGI | Initiate a P_LOGI to the Requester | 1029 +----------+----------------+--------------------------------------+ 1030 | 1 | INIT_REPLY | Send FARP_REPLY to Requester | 1031 +----------+----------------+--------------------------------------+ 1032 | 2 to 7 | Reserved | | 1033 +----------+----------------+--------------------------------------+ 1035 If INIT_P_LOGI bit is set then, a Login is performed with the port 1036 identified by "Port_ID of Requester" field. 1038 If INIT_REPLY is set then, a FARP-REPLY is sent to the Port 1039 Identified by "Port_ID of Requester" field 1041 If both bits are set at the same time, then, a FARP-REPLY is sent 1042 followed by a Login to the port identified by "Port_ID of Requester" 1043 field. 1045 All other bit patterns are undefined at this time and are reserved 1046 for possible future use. 1048 5.6 FARP Support Requirements 1050 Responder action - FARP-REPLY and/or Port Login - for a successful 1051 MATCH_WW_PN is always required. 1053 Support for all other match Address Code Points is optional and a 1054 silent behavior from the Responder is valid when it is not supported. 1055 Recipients of the FARP-REQ ELS shall not issue a Service Reject 1056 (LS_RJT) if FARP options are not supported 1058 In all cases if there are no matches, then a silent behavior is 1059 valid. 1061 If an implementation issues a FARP-REQ with a Match Address Code 1062 Point that is optional, and fails to receive a response, then it may 1063 conclude that this particular option is either not supported or there 1064 are no address matches. 1066 If it concludes, that this Match Address Code Point may not be 1067 supported then, it may reattempt the FARP-REQ with the MATCH_WW_PN 1068 Code Point. 1070 Getting multiple FARP Replies corresponding to a single FARP-REQ 1071 should normally never occur. It is beyond the scope of this document 1072 to specify conditions under which this error may occur or what the 1073 corrective action ought to be. 1075 6. Exchange Management 1077 6.1 Exchange Origination 1079 FC Exchanges shall be established to transfer data between ports. 1080 Frames on IP exchanges shall not transfer Sequence Initiative. See 1081 Appendix E for a brief discussion on FC exchanges. 1083 6.2 Exchange Termination 1085 With the exception of the recommendations in Appendix F, Section F.1, 1086 "Reliability in Class 3", the mechanism for aging or expiring 1087 exchanges based on activity, timeout, or other method is outside the 1088 scope of this document. 1090 Exchanges may be terminated by either port. The Exchange Originator 1091 may terminate Exchanges by setting the LS bit, following normal FC 1092 standard FC-PH [2] rules. This specification prohibits the use of the 1093 NOP ELS with LS set for Exchange termination. 1095 Exchanges may be torn down by the Exchange Originator or Exchange 1096 Responder by using the ABTS_LS protocol. The use of ABTS_LS for 1097 terminating aged exchanges or error recovery is outside the scope of 1098 this document. 1100 The termination of IP exchanges by Logout is discouraged, since this 1101 may terminate active exchanges on other FC-4s. 1103 7. Summary of Supported Features 1105 Note: 'Required' means the feature support is mandatory, 'Prohibited' 1106 means the feature support is not valid, and 'Settable' means support 1107 is as specified in the relevant standard. 1109 7.1 FC-4 Header 1110 +--------------------------------------------------------------------+ 1111 | Feature | Support | Notes | 1112 +--------------------------------------------------------------------+ 1113 | Type Code ( = 5) ISO8802-2 LLC/SNAP | Required | 2 | 1114 | Network Headers | Required | 3 | 1115 | Other Optional Headers | Prohibited | | 1116 +--------------------------------------------------------------------+ 1118 Notes: 1120 1. This table applies only to FC-4 related data, such as IP and 1121 ARP packets. This table does not apply to link services and 1122 other non-FC-4 sequences (PLOGI, for example) that must occur 1123 for normal operation. 1125 2. The TYPE field in the FC Header (Word 2 bits 31-24) must 1126 indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This 1127 revision of the document focuses solely on the issues related 1128 to running IP and ARP over FC. All other issues are outside 1129 the scope of this document, including full support for IEEE 1130 802.2 LLC. 1132 3. DF_CTL field (Word 3, bits 23-16 of FC-Header)must indicate 1133 the presence of a Network Header (0010 0000) on the First 1134 logical Frame of FC-4 sequences. 1136 7.2 R_CTL 1138 R_CTL in FC-Header: Word 0, bits 31-24 1140 +--------------------------------------------------------------------+ 1141 | Feature | Support | Notes | 1142 +--------------------------------------------------------------------+ 1143 | Information Category (R_CTL Routing): | | | 1144 | | | | 1145 | FC-4 Device Data | Required | 1 | 1146 | Extended Link Data | Required | 2 | 1147 | FC-4 Link Data | Prohibited | | 1148 | Video Data | Prohibited | | 1149 | Basic Link Data | Required | 3 | 1150 | Link Control | Required | 4 | 1151 | | | | 1152 | R_CTL information : | | | 1153 | | | | 1154 | Uncategorized | Prohibited | | 1155 | Solicited Data | Prohibited | | 1156 | Unsolicited Control | Required | 2 | 1157 | Solicited Control | Required | 2 | 1158 | Unsolicited Data | Required | 1 | 1159 | Data Descriptor | Prohibited | | 1160 | Unsolicited Command | Prohibited | | 1161 | Command Status | Prohibited | | 1162 +--------------------------------------------------------------------+ 1164 Notes: 1166 1. This is required for FC-4 (IP and ARP) packets 1168 - Routing bits of R_CTL field must indicate Device Data 1169 frames (0000) 1170 - Information Category of R_CTL field must indicate 1171 Unsolicited Data (0100) 1173 2. This is required for Extended Link Services. 1175 3. This is required for Basic Link Services. 1177 4. This is required for Link Control frames. 1179 7.3 F_CTL 1181 F_CTL in FC-Header: Word 2, bits 23-0 1182 +--------------------------------------------------------------------+ 1183 | Feature | Support | Notes | 1184 +--------------------------------------------------------------------+ 1185 | Exchange Context | Settable | | 1186 | Sequence Context | Settable | | 1187 | First / Last / End Sequence (FS/LS/ES) | Settable | | 1188 | Chained Sequence | Prohibited | | 1189 | Sequence Initiative (SI) | Settable | 1 | 1190 | X_ID Reassigned / Invalidate | Prohibited | | 1191 | Unidirectional Transmit | Settable | | 1192 | Continue Sequence Condition | Required | 2 | 1193 | Abort Seq. Condition -continue and single seq.| Required | 3 | 1194 | Relative Offset - Unsolicited Data | Settable | 4 | 1195 | Fill Bytes | Settable | | 1196 +--------------------------------------------------------------------+ 1197 Notes: 1198 1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for 1199 sending data to each N_Port in the network and a dedicated 1200 RX_ID for receiving data from each N_Port as well. Exchanges 1201 are used in a unidirectional mode, thus setting sequence 1202 initiative is not valid for FC-4 frames. Sequence initiative 1203 is valid when using Extended Link Services. 1204 2. This field is required to be 00, no information. 1205 3. Sequence error policy is requested by an exchange originator 1206 in the F_CTL Abort Sequence Condition bits in the first data 1207 frame of the exchange. For classes 1 and 2, ACK frame is 1208 required to be "continuous sequence". 1209 4. Relative offset prohibited on all other types (Information 1210 Category) of frames. 1212 7.4 Sequences 1214 +---------------------------------------------------------------------+ 1215 | Feature | Support |Notes | 1216 +---------------------------------------------------------------------+ 1217 | Class 2 open sequences / exchange | 1 | 1 | 1218 | Length of seq. not limited by end-to-end credit | Required | 2 | 1219 | IP and ARP Packet and FC Payload Sizes | Required | 3 | 1220 | Capability to receive sequence of maximum size | Optional | 4 | 1221 | Sequence Streaming | Prohibited | 5 | 1222 | Stop Sequence Protocol | Prohibited | | 1223 | ACK_0 support | Optional | 6 | 1224 | ACK_1 support | Required | 6 | 1225 | ACK_N support | Prohibited | | 1226 | Class of Service for transmitted sequences | 1, 2 or 3 | 7 | 1227 | Continuously Increasing Sequence Count | Optional | 8, 9 | 1228 +---------------------------------------------------------------------+ 1229 Notes: 1230 1. Only one active sequence per exchange is optional. 1232 2. A sequence initiator shall be capable of transmitting 1233 sequences containing more frames than the available credit 1234 indicated by a sequence recipient at login. FC-PH [2] end-to 1235 end flow control rules will be followed when transmitting such 1236 sequences. 1238 3. a) IP MTU size is 65280 bytes and resulting FC MTU size is 1239 65536 bytes. 1240 b) Maximally Min IP packet size is 68 bytes and resulting 1241 Maximally Min FC Payload size is 92 bytes. 1242 c) ARP packet (and InARP) is 28 bytes and resulting FC 1243 Payload size is 52 bytes. 1245 4. Some OS environments may not handle the max MTU of 65536. It 1246 is up to the administrator to configure the Max MTU for all 1247 systems. 1249 5. All class 3 sequences are assumed to be non-streamed. 1251 6. Only applies for Class 1 and 2. Use of ACK_1 is default, 1252 ACK_0 used if indicated by sequence recipient at login. 1254 7. The administrator configured class of service is used, except 1255 where otherwise specified (e.g. Broadcasts are always sent in 1256 class 3). 1258 8. Review Appendix E, "Reliability in Class 3". 1260 9. The first frame of the first sequence of anew exchange must 1261 have SEQ_CNT = 0 [2]. 1263 7.5 Exchanges 1264 +--------------------------------------------------------------------+ 1265 | Feature | Support | Notes | 1266 +--------------------------------------------------------------------+ 1267 | X_ID interlock support | Optional | 1 | 1268 | OX_ID=FFFF | Prohibited | | 1269 | RX_ID=FFFF | Optional | 2 | 1270 | Action if no exchange resources available | P_RJT | 3 | 1271 | Long Lived Exchanges | Optional | 4 | 1272 | Reallocation of Idle Exchanges | Optional | | 1273 +--------------------------------------------------------------------+ 1274 Notes: 1275 1. Only applies to Classes 1 and 2, supported by the exchange 1276 originator. A Port shall be capable of interoperating with 1277 another Port that requires X_ID interlock. The exchange 1278 originator facility within the Port shall use the X_ID 1279 Interlock protocol in such cases. 1281 2. An exchange responder is not required to assign RX_IDs. If a 1282 RX_ID of FFFF is assigned, it is identifying exchanges based 1283 on S_ID / D_ID / OX_ID only. 1285 3. In Classes 1 and 2, a Port shall reject a frame that would 1286 create a new exchange with a P_RJT containing reason code 1287 "Unable to establish exchange". In Class 3, the frame would 1288 be dropped. 1290 4. When an exchange is created between 2 Ports for IP/ARP data, 1291 it remains active while the ports are logged in with each 1292 other. An exchange shall not transfer Sequence Initiative 1293 (SI). Broadcasts and ELS commands may use short lived 1294 exchanges. 1296 7.6 ARP and InARP 1297 +--------------------------------------------------------------------+ 1298 | Feature | Support | Notes | 1299 +--------------------------------------------------------------------+ 1300 | ARP Server Support | Prohibited | 1 | 1301 | Response to ARP requests | Required | 2 | 1302 | Class of Service for ARP requests | 3 | 3 | 1303 | Class of Service for ARP replies | 1, 2 or 3 | 4 | 1304 | Response to InARP requests | Optional | | 1305 | Class of Service for InARP requests/replies | 1, 2 or 3 | 5 | 1306 +--------------------------------------------------------------------+ 1307 Notes: 1308 1. Well-known Address FFFFFC is not used for ARP requests. Frames 1309 from Well-known address FFFFFC are not considered to be ARP 1310 frames. Broadcast support is required for ARP. 1312 2. The IP Address is mapped to a specific MAC address with ARP. 1314 3. An ARP request is a broadcast Sequence, thus Class 3 is always 1315 used. 1317 4. An ARP reply is a normal sequence, thus the administrator 1318 configured class of service is used. 1320 5. An InARP Request or Reply is a normal sequence, thus an 1321 administrator configured class of service is used. 1323 7.7 Extended Link Services (ELS) 1325 +--------------------------------------------------------------------+ 1326 | Feature | Support | Notes | 1327 +--------------------------------------------------------------------+ 1328 | Class of service for ELS commands / responses | 1,2 or 3 | 1 | 1329 | Explicit N-Port Login | Required | | 1330 | Explicit F-Port Login | Required | | 1331 | FLOGI ELS command | Required | | 1332 | PLOGI ELS command | Required | | 1333 | ADISC ELS command | Required | | 1334 | PDISC ELS command | Optional | 2 | 1335 | FAN ELS command | Required | 5 | 1336 | LOGO ELS command | Required | | 1337 | FARP-REQ/FARP-REPLY ELS commands | Required | 3 | 1338 | Other ELS command support | Optional | 4 | 1339 +-----------------------------------------------+------------+-------+ 1340 Notes: 1341 1. The administrator configured class of service is used. 1343 2. PDISC is prohibited as requester; ADISC should be used 1344 instead. As a responder, an implementation may need to respond 1345 to both ADISC and PDISC for compatibility with other 1346 specifications. 1348 3. Responder action - FARP-REPLY and/or Port Login - for a 1349 successful MATCH_WW_PN is always required. 1350 Support for all other match Address Codes Points is optional; 1351 a silent behavior from the Responder is valid when it is not 1352 supported. 1353 Recipients of the FARP-REQ ELS shall not issue a Service 1354 Reject (LS_RJT) if FARP is not supported 1356 4. If other ELS commands are received an LS_RJT may be sent. NOP 1357 is not required by this specification, and should not be used 1358 as a mechanism to terminate exchanges. 1360 5. Required for FL_Ports 1362 7.8 Login Parameters 1364 Unless explicitly noted here, a compliant implementation shall use 1365 the login parameters as described in [4]. 1367 7.8.1 Common Service Parameters - FLOGI 1369 - FC-PH Version, lowest version may be 0x09 to indicate 1370 'minimum 4.3'. 1371 - Can't use BB_Credit=0 for N_Port on a switched Fabric 1372 (F_Port). 1374 7.8.2 Common Service Parameters - PLOGI 1376 - FC-PH Version, lowest version may be 0x09 to indicate 1377 'minimum 4.3'. 1378 - Can't use BB_Credit=0 for N_Port in a Point-to-Point 1379 configuration 1381 - Random Relative Offset is optional. 1383 - Note that the 'Receive Data Field Size' fields specified in 1384 the PLOGI represent both optional headers and payload. 1386 - The MAC Address can therefore be extracted from the 6 lower 1387 bytes of the WW_PN field (when the IEEE 48-bit Identifier 1388 format is chosen as the NAA) during PLOGI or ACC payload 1389 exchanged during Fibre Channel Login [2]. 1391 - The MAC Address can also be extracted from the WW_PN field in 1392 the Network Header during ADISC (and ADISC ACC), or PDISC 1393 (and PDISC ACC). 1395 7.8.3 Class Service Parameters - PLOGI 1397 - Discard error policy only. 1399 8. Security Considerations 1401 FC frames are CRC protected for the header and payload using ANSI 1402 X3.139 specified 32-polynomial used with FDDI. Manipulation of header 1403 information without regenerating a new one will be easily detected. 1404 Independent of IP and ARP, Fibre Channel protocols do have special 1405 issues with security. Use of IP or ARP over FC does not introduce 1406 new security threats and is for most part transparent. 1408 The mappings should be valid at all times. There are 1409 many events that can invalidate this mapping. Appendix D discusses 1410 conditions when a validation is required. This type of validation is 1411 normally performed in FC and does not require special consideration 1412 in this document. 1414 9. Acknowledgement 1416 This specification is based on FCA IP Profile, Version 3.3. The FCA 1417 IP Profile was a joint work of the Fibre Channel Association (FCA) 1418 vendor community. The following companies and organizations have 1419 contributed to the creation of the FCA IP Profile: Adaptec, Ancor, 1420 Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar, 1421 Gadzoox, Hewlett Packard, Interphase, Jaycor, McData, Migration 1422 Associates, Orca Systems, Prisa, Q-Logic, Symbios, Systran, 1423 Tektronix, Univ. of Minnesota, Univ. of New Hamshire. Jon Infante 1424 from Emulex deserves special mention for his contributions to the 1425 FARP Protocol. The authors extend their thanks to all who provided 1426 comments. 1428 10. References 1430 [1] FCA IP Profile, Revision 3.3, May 15, 1997 1432 [2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI 1433 X3.230-1994 1435 [3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1436 1996 1438 [4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.7, August 1439 12, 1997 1441 [5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), 1442 Rev. 2.1, September 22, 1997 1444 [6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), 1445 Rev. 7.4, ANSI X3.297-1996 1447 [7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996 1449 [8] Postel, J. and Reynolds, J., "A standard for the Transmission of 1450 IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, Feb, 1988 1452 [9] Plummer, D. "An Ethernet Address Resolution Protocol -or- 1453 Converting Network Addresses to 48-bit Ethernet Address for 1454 Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, Nov 1455 1982. 1457 [10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995 1459 [11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), 1460 Rev. 9.3, ANSI X3.xxx-199x 1462 [12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", 1463 Ancot Corporation 1465 [13] Fibre Channel -Gigabit Communications and I/O for Computers 1466 Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2 1468 [14] Fibre Channel Generic Services -2 (FC-GS-2), Rev. 5.2 1469 X3.288-199x 1471 [15] RFC 1293: Inverse Address Resolution Protocol. 1472 T. Bradley, C. Brown. Jan. 1992, PROPOSED STD, 1473 Obsoleted by RFC 2390 1475 [16] RFC 2390: Inverse Address Resolution Protocol. 1476 T. Bradley, C. Brown, A. Malis Aug. 1992, DRAFT STD 1478 [17] RFC 791: Internet Protocol. J. Postel. Sep 01-1981. 1479 STANDRAD 1481 [18] The Fibre Channel Consultant: A Comprehensive Introduction, 1482 "Robert W. Kembel", Northwest Learning Associates, 1998 1484 11. Authors' Addresses 1486 Murali Rajagopal 1487 Gadzoox Networks, Inc. 1488 711 Kimberly Avenue, Suite 100 1489 Placentia, CA 92870 1491 Phone: +1 714 577 6805 1492 Fax: +1 714 524 8508 1493 Email: murali@gadzoox.com 1495 Raj Bhagwat 1496 Gadzoox Networks, Inc. 1497 711 Kimberly Avenue, Suite 100 1498 Placentia, CA 92870 1500 Phone: +1 714 577 6806 1501 Fax: +1 714 524 8508 1502 Email: raj@gadzoox.com 1504 Wayne Rickard 1505 Gadzoox Networks, Inc. 1506 711 Kimberly Avenue, Suite 100 1507 Placentia, CA 92870 1509 Phone: +1 714 577 6803 1510 Fax: +1 714 524 8508 1511 Email: wayne@gadzoox.com 1513 Appendix A: Additional Matching Mechanisms in FARP 1515 Section 5 described the FC Layer mapping between the WW_PN and the 1516 Port_ID using the FARP Protocol. This appendix describes other 1517 optional criteria for address matching and include: 1519 - WW_NN 1520 - WW_PN & WW_NN at the same time 1521 - IPv4 1522 - IPv4 & WW_PN at the same time 1523 - IPv4 & WW_PN & WW_NN at the same time 1525 Depending on the Match Address Code Points, the FARP protocol 1526 fundamentally resolves three main types of addresses to Port_IDs and 1527 is described in table below. 1529 - For Match Address Code Point b'001': 1530 WW_PN Names fields are used to resolve the WW_PN names to 1531 Port_IDs. 1532 WW_NN and IP address fields are not used with these Code Points 1533 and shall be set to either '0' or valid addresses by Requester 1534 or Requester and Responder. 1536 - For Match Address Code Point b'010': 1537 WW_NN Names fields are used to resolve the WW_NN names to 1538 Port_IDs. 1539 WW_PN and IP address fields are not used with these Code Points 1540 and shall be set to either '0' or valid addresses by Requester 1541 or Requester and Responder. 1543 - For Match Address Code Point b'100': 1544 IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. 1545 WW_PN and WW_NN fields are not used with these Code Points and 1546 shall be set to either '0' or valid addresses by Requester or 1547 Requester and Responder. 1549 - For all other Match Address Code Points b'011', b'101',b'110', 1550 b'111', depending on set bits one or more addresses are jointly 1551 resolved to a Port_ID. See table below. If fields are not used, 1552 then they are set either to '0' or valid addresses 1554 The Responder Flags remain the same as before. Note that there can be 1555 utmost one FARP-REPLY per FARP-REQ. 1557 Tables showing FARP-REQ and FARP-REPLY and address fields setting are 1558 given below: 1560 +--------------------------------------------------------------------+ 1561 | Match Address Code Points | 1562 +--------------------------------------------------------------------+ 1563 | LSBits| Bit name | Action | 1564 +-------+--------------------+---------------------------------------+ 1565 | 000 | Reserved | | 1566 +-------+--------------------+---------------------------------------+ 1567 | 001 | MATCH_WW_PN | If 'WW_PN of Responder' = | 1568 | | | Node's WW_PN then respond | 1569 +-------+--------------------+---------------------------------------+ 1570 | 010 | MATCH_WW_NN | If 'WW_NN of Responder' = | 1571 | | | Node's WW_NN then respond | 1572 +-------+--------------------+---------------------------------------+ 1573 | 011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & | 1574 | | | 'WW_NN of Responder' = | 1575 | | | Node's WW_PN & WW_NN then respond | 1576 +-------+--------------------+---------------------------------------+ 1577 | 100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = | 1578 | | | Node's IPv4 Address then respond | 1579 +-------+--------------------+---------------------------------------+ 1580 | 101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = | 1581 | | | Node's WW_PN and IPv4 then respond | 1582 +-------+--------------------+---------------------------------------+ 1583 | 110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & | 1584 | | | 'IPv4 Address of Responder' = | 1585 | | | Node's WW_NN & IPv4 then respond | 1586 +-------+--------------------+---------------------------------------+ 1587 | 111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & | 1588 | | | 'WW_NN of Responder' & | 1589 | | | 'IPv4 Address of Responder' = | 1590 | | | Nodes' WW_PN & WW_NN & IPv4 | 1591 | | | then respond | 1592 +-------+--------------------+---------------------------------------+ 1594 +---------------------------------------------------------------------+ 1595 | FARP-REQ Command | 1596 +-------------------------------+---------+---------------------------+ 1597 | Field | Size | Remarks | 1598 | | (Bytes) | | 1599 +-------------------------------+---------+---------------------------+ 1600 | 0x54-00-00-00 | 4 | Request Command Code | 1601 +-------------------------------+---------+---------------------------+ 1602 | Match Address Code Points | 1 | Indicates Address | 1603 | | | Matching Mechanism | 1604 +-------------------------------+---------+---------------------------+ 1605 | Port_ID of Requester | 3 |Supplied by Requester | 1606 +-------------------------------+---------+---------------------------+ 1607 | Responder Flags | 1 |Response Action to be taken| 1608 +-------------------------------+---------+---------------------------+ 1609 | Port_ID of Responder | 3 | Set to 0x00-00-00 | 1610 +-------------------------------+---------+---------------------------+ 1611 |WW_PN of Requester | 8 | Supplied by Requester | 1612 +-------------------------------+---------+---------------------------+ 1613 |WW_NN of Requester | 8 |OPTIONAL; | 1614 | | |Supplied by Requester | 1615 +-------------------------------+---------+---------------------------+ 1616 |WW_PN of Responder | 8 |Supplied by Requester | 1617 +-------------------------------+---------+---------------------------+ 1618 |WW_NN of Responder | 8 |OPTIONAL ;Supplied by | 1619 | | |Requester or Responder | 1620 +-------------------------------+---------+---------------------------+ 1621 |IP Add. of Requester | 16 |OPTIONAL; Supplied by | 1622 | | |Requester | 1623 | | |IPv4 Add.=low 32 bits | 1624 +-------------------------------+---------+---------------------------+ 1625 |IP Address of Responder | 16 |OPTIONAL; Supplied by | 1626 | | |Requester or Responder | 1627 | | |IPv4 Add.=low 32 bits | 1628 +-------------------------------+---------+---------------------------+ 1630 +---------------------------------------------------------------------+ 1631 | FARP-REPLY Command | 1632 +-------------------------------+---------+---------------------------+ 1633 | Field | Size | Remarks | 1634 | | (Bytes) | | 1635 +-------------------------------+---------+---------------------------+ 1636 | 0x55-00-00-00 | 4 |Reply Command Code | 1637 +-------------------------------+---------+---------------------------+ 1638 | Match Address Code Points | 1 | Not Used and unchanged | 1639 | | |from the FARP-REQ | 1640 +-------------------------------+---------+---------------------------+ 1641 | Port_ID of Requester | 3 |Supplied by Requester | 1642 +-------------------------------+---------+---------------------------+ 1643 | Responder Flags | 1 | Not Used and unchanged | 1644 | | |from the FARP-REQ | 1645 +-------------------------------+---------+---------------------------+ 1646 | Port_ID of Responder | 3 |Supplied by Responder | 1647 +-------------------------------+---------+---------------------------+ 1648 |WW_PN of Requester | 8 |Supplied by Requester | 1649 +-------------------------------+---------+---------------------------+ 1650 |WW_NN of Requester | 8 |OPTIONAL; Supplied by | 1651 | | |Requester | 1652 +-------------------------------+---------+---------------------------+ 1653 |WW_PN of Responder | 8 |Supplied by Requester | 1654 +-------------------------------+---------+---------------------------+ 1655 |WW_NN of Responder | 8 |OPTIONAL; Supplied by | 1656 | | |Requester or Responder | 1657 +-------------------------------+---------+---------------------------+ 1658 |IP Add. of Requester | 16 |OPTIONAL; Supplied by | 1659 | | |Requester | 1660 | | |IPv4 Add.=low 32 bits | 1661 +-------------------------------+---------+---------------------------+ 1662 |IP Address of Responder | 16 |OPTIONAL; Supplied by | 1663 | | |Requester or Responder | 1664 | | |IPv4 Add.=low 32 bits | 1665 +-------------------------------+---------+---------------------------+ 1667 Appendix B: InARP 1669 B.1 General Discussion 1671 Inverse ARP (InARP) is a mechanism described in RFC 1293/2390 [15, 1672 16], which is useful when a node desires to know the protocol address 1673 of a target node whose hardware address is known. Situations where 1674 this could occur are described in [15, 16]. The motivation for using 1675 InARP in FC is to allow a node to learn the IP address of another 1676 node with which it has performed a Port Login (PLOGI). PLOGI is a 1677 normal FC process that happens between nodes, independent of this 1678 standard. PLOGI makes it possible for a node to discover the WW_PN 1679 and the Port_ID of the other node but not its IP address. A node in 1680 this way may potentially obtain the IP address of all nodes with 1681 which it can PLOGI. 1683 Note that use of the InARP mechanism can result in resolving all 1684 WW_PN to IP addresses and ARP may no longer be required. This can be 1685 beneficially applied in cases where a particular FC topology makes it 1686 inefficient to send out an ARP broadcast. 1688 B.2 InARP Protocol Operation 1690 InARP uses the same ARP packet format but with different 'Op Codes', 1691 one for InARP Request and another for InARP Reply. 1693 The InARP protocol operation is very simple. The requesting node 1694 fills the hardware address (WW_PN) of the target device and sets the 1695 protocol address to 0x00-00-00-00. Because, the request is sent to a 1696 node whose WW_PN and Port_ID are known, there is no need for a 1697 broadcast. The target node fills in its Protocol address (IP address 1698 in this case) and sends an InARP Reply back to the sender. A node 1699 may collect, all such WW_PN and IP addresses pairs in a similar way. 1701 B.3 InARP Packet Format 1703 Since the InARP protocol uses the same packet format as the ARP 1704 protocol, much of the discussion on ARP formats given in Section 4 1705 applies here. 1707 The InARP is 28 bytes long in this application and uses two messages: 1708 Request and Reply. Like ARP, the InARP Packet fields are common to 1709 both InARP Requests and InARP Replies. 1711 An InARP Request and Reply Packets are encapsulated in a single 1712 frame FC sequence just like ARP. Compliant InARP Request and Reply FC 1713 Sequences shall include Network headers. 1715 The 'HW Type' field shall be set to 0x00-01. 1717 The 'Protocol' field shall be set to 0x08-00 indicating IP protocol. 1719 The 'HW Addr Length' field shall be set to 0x06 indicating 6 bytes of 1720 HW address. 1722 The 'Protocol Addr Length' field shall be set to 0x04 indicating 4 1723 bytes of IP address. 1725 The 'Operation' Code field shall be set as follows: 1727 0x00-08 for InARP Request 1728 0x00-09 for InARP Reply 1730 The 'HW Addr of Sender' field shall be the 6 byte IEEE MAC address of 1731 the Requester (InARP Request) or Responder (InARP Reply). 1733 The 'Protocol Addr of Sender' field shall be the 4 byte IP address of 1734 the Requester (InARP Request) or Responder (InARP Reply). 1736 The 'HW Addr of Target' field shall be set to the 6 byte MAC address 1737 of the Responder in an InARP Request and to the 6 byte MAC address of 1738 the Requester in an InARP Reply. 1740 The 'Protocol Addr of Target' field shall be set to 0x00-00-00-00 in 1741 an InARP Request and to the 4-byte IP address of the Requester in an 1742 InARP Reply. 1744 B.4 InARP Support Requirements 1746 Support for InARP is optional. If a node does not support InARP and 1747 it receives an InARP Request message then a silent behavior is 1748 acceptable. 1750 APPENDIX C: Some Informal Mechanisms for FC Layer Mappings 1752 Each method should have some check to ensure PLOGI has completed 1753 successfully before data is sent. A related concern in large networks 1754 is limiting concurrent logins to only those ports with active IP 1755 traffic. 1757 C.1 Login on Cached Mapping Information 1759 This method insulates the level performing LOGIN from the level 1760 interpreting ARP. It is more accommodating of non-ARP mechanisms for 1761 building the FC-layer mapping table. 1763 1. Broadcast messages that carry a Network Header contain 1764 the S_ID on the FC-header and WW_PN in the Network-header. 1765 Caching this information provides a correlation of Port_ID to 1766 WW_PN. If the received Broadcast message is compliant with 1767 this specification, the WW_PN will be the MAC Address. 1769 2. The WW_PN is "available" if Login has been performed to the 1770 Port_ID and flagged. If login has not been performed, the 1771 WW_PN is "unavailable". 1773 3. If an outbound packet is destined for a port that is 1774 "unavailable", the cached information (from broadcast) is used 1775 to look up the Port_ID. 1777 4. After sending an ELS PLOGI command (Port Login) to the Port 1778 (from a higher level entity at the host), waiting for an 1779 outbound packet before sending this Port Login conserves 1780 resources for only for those ports which wish to establish 1781 communication. 1783 5. After Port Login completes (ACC received), the outbound packet 1784 can be forwarded. At this point in time, both ends have the 1785 necessary information to complete their association. 1788 C.2 Login on ARP Parsing 1790 This method performs LOGIN sooner by parsing ARP before passing it up 1791 to higher levels for IP/MAC Address correlation. It requires a low- 1792 level awareness of the IP address, and is therefore protocol- 1793 specific. 1795 1. When an ARP Broadcast Message is received, the S_ID is 1796 extracted from the FC header and the corresponding 1797 Network_Source_Address from the Network Header. 1799 2. The ARP payload is parsed to determine if 1800 (a) this host is the target of the ARP request (Target IP 1801 Address match), and 1802 (b) if this host is currently logged in with the port 1803 (Port_ID = S_ID) originating the ARP broadcast. 1805 3. The ARP is passed to higher level for ARP Response generation. 1807 4. If a Port Login is required, an ELS PLOGI command (Port Login) 1808 is sent immediately to the Port originating the ARP Broadcast. 1810 5. After Port Login completes, an ARP response can be forwarded. 1811 Note that there are two possible scenarios: 1813 - The ACC to PLOGI returns before the ARP reply is processed 1814 and the ARP Reply is immediately forwarded. 1815 - The ARP reply is delayed, waiting for ACC (successful 1816 Login). 1818 6. At this point in time, both ends have the necessary 1819 information to complete their 1820 association. 1822 C.3 Login to Everyone 1824 In Fibre Channel topologies with a limited number of ports, it may be 1825 efficient to unconditionally login to each port. This method is 1826 discouraged in fabric and public loop environments. 1828 After Port Login completes, the MAC Address to Port_ID Address tables 1829 can be constructed. 1831 C.4 Static Table 1833 In some loop environments with a limited number of ports, a static 1834 mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be 1835 maintained. The FC layer will always know the destination Port_ID 1836 based on the table. The table is typically downloaded into the driver 1837 at configuration time. This method scales poorly, and is therefore 1838 not recommended. 1840 Appendix D. FC Layer Address Validation 1842 D.1 General Discussion 1844 At all times, the mapping has to be valid before 1845 use. There are many events that can invalidate this mapping. The 1846 following discussion addresses conditions when such a validation is 1847 required. 1849 After a FC link interruption occurs, the Port_ID of a port may 1850 change. After the interruption, the Port_IDs of all other ports that 1851 have previously performed PLOGI (N_Port Login) with this port may 1852 have changed, and its own Port_ID may have changed. 1854 Because of this, address validation is required after a LIP in a loop 1855 topology [7] or after NOS/OLS in a point-to-point topology [6]. 1857 Port_IDs will not change as a result of Link Reset (LR),thus address 1858 validation is not required. 1860 In addition to actively validating devices after a link interruption, 1861 if a port receives any FC-4 data frames (other than broadcast 1862 frames), from a port that is not currently logged in, then it shall 1863 send an explicit Extended Link Service (ELS) Request logout (LOGO) 1864 command to that port. 1866 ELS commands (Requests and Replies) are used by an N_Port to solicit 1867 a destination port (F_Port or N_Port) to perform some link-level 1868 function or service.) The LOGO Request is used to request 1869 invalidation of the service parameters and Port_ID of the recipient 1870 N_Port. 1872 The level of initialization and subsequent validation and recovery 1873 reported to the upper (FC-4) layers is implementation-specific. 1875 In general, an explicit Logout (LOGO) shall be sent whenever the FC- 1876 Layer mapping between the Port_ID and WW_PN of a remote port is 1877 removed. 1879 The effect of power-up or re-boot on the mapping tables is outside 1880 the scope of this specification. 1882 D.2 FC Layer Address Validation in a Point-to-Point Topology 1884 No validation is required after LR. In a point-to-point topology, 1885 NOS/OLS causes implicit logout of each port and after a NOS/OLS, each 1886 port must perform a PLOGI [2]. 1888 D.3 FC Layer Address Validation in a Private Loop Topology 1890 After a LIP, a port shall not transmit any link data to another port 1891 until the address of the other port has been validated. The 1892 validation consists of completing either ADISC or PDISC. (See 1893 Appendix G.) 1895 ADISC (Address Discovery) is an ELS command for discovering the hard 1896 addresses - the 24-bit identifier- of NL_Ports [5], [6]. 1898 PDISC (Discover Port) is an ELS command for exchanging service 1899 parameters without affecting login state [5], [6]. 1901 As a requester, this specification prohibits PDISC and requires 1902 ADISC. 1904 As a responder, an implementation may need to respond to both ADISC 1905 and PDISC for compatibility with other FC specifications. 1907 If the three addresses, Port_ID, WW_PN, WW_NN, exactly match the 1908 values prior to the LIP, then any active exchanges may continue. 1910 If any of the three addresses have changed, then the node must be 1911 explicitly logged out [4], [5]. 1913 If a port's N_Port ID changes after a LIP, then all active Port-ID to 1914 WW_PN mappings at this port must be explicitly logged out. 1916 D.4 FC Layer Address Validation in a Public Loop Topology 1918 A FAN (Fabric Address Notification) ELS command is sent by the fabric 1919 to all known previously logged in ports following an initialization 1920 event. Therefore, after a LIP, hosts may wait for this notification 1921 to arrive or they may perform a FLOGI. 1923 If the WW_PN and WW_NN of the fabric FL_Port contained in the FAN ELS 1924 or FLOGI response exactly match the values before the LIP, and if the 1925 AL_PA obtained by the port is the same as the one before the LIP, 1926 then the port may resume all exchanges. If not, then FLOGI (Fabric 1927 Login) must be performed with the fabric and all nodes must be 1928 explicitly logged out. 1930 A public loop device will have to perform the private loop 1931 authentication to any nodes on the local loop which have an Area + 1932 Domain Address == 0x00-00-XX 1934 D.5 FC Layer Address Validation in a Fabric Topology 1936 No validation is required after LR (link reset). 1938 After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID 1939 of the port, the WW_PN of the fabric, and the WW_NN of the fabric are 1940 the same as before the NOS/OLS, then the port may resume all 1941 exchanges. If not, all nodes must be explicitly, logged out [2]. 1943 APPENDIX E: Fibre Channel Overview 1945 E.1 Brief Tutorial 1947 The FC Standard [2] defines 5 "levels" (not layers) for its protocol 1948 description: FC-0, FC-1, FC-2, FC-3, and FC-4. The first three levels 1949 (FC-0, FC-1, FC-2) are largely concerned with the physical formatting 1950 and control aspects of the protocol. FC-3 has been architected to 1951 provide a place holder for functions that might need to be performed 1952 after the upper layer protocol has requested the transmission of an 1953 information unit, but before FC-2 is asked to deliver that piece of 1954 information by using a sequence of frames [19]. At this time, no FC-3 1955 functions have been defined FC-4 is meant for supporting profiles of 1956 Upper Layer Protocols (ULP) such as IP and Small Computer System 1957 Interface (SCSI), and supports a relatively small set of compared to 1958 LAN protocols such as IEEE 802.3. 1960 FC devices are called "Nodes", each of which has at least one "Port" 1961 to connect to other ports. A Node may be a workstation, a disk drive 1962 or disk array, a camera, a display unit, etc. The set of hardware 1963 components, and transceivers, connecting two or more node ports is 1964 called a topology. 1966 A "Link" is two unidirectional paths flowing in opposite directions 1967 and connecting two Ports within adjacent Nodes. 1969 FC Nodes communicate using higher layer protocols such as SCSI and IP 1970 and are configured to operate using one of the following networking 1971 topologies: 1973 - Point-to-Point 1975 - Private Loop 1977 - Public Loop (attachment to a Fabric) 1979 - Fabric 1981 The point-to-point is the simplest of the four topologies, where only 1982 two nodes communicate with each other. The private loop may connect a 1983 number of devices (max 126) in a logical ring much like Token Ring 1984 and is distinguished from a public loop by the absence of a Fabric 1985 Node participating in the loop. The Fabric topology is a switched 1986 network where any attached node can communicate with any other. For a 1987 detail description of FC topologies refer to [18]. 1989 Table below summarizes the usage of port types depending on its 1990 location [12]. Note that E-Port is not relevant to any discussion in 1991 this specification but is included below for completeness. 1993 +-----------+-------------+-----------------------------------------+ 1994 | Port Type | Location | Topology Associated with | 1995 +-----------+-------------+-----------------------------------------+ 1996 | N_Port | Node | Point-to-Point or Fabric | 1997 +-----------+-------------+-----------------------------------------+ 1998 | NL_Port | Node |In N_Port mode -Point-to-Point or Fabric | 1999 | | |In NL_Port mode - Arbitrated Loop | 2000 +-----------+-------------+-----------------------------------------+ 2001 | F_Port | Fabric | Fabric | 2002 +-----------+-------------+-----------------------------------------+ 2003 | FL_Port | Fabric | In F_Port mode - Fabric | 2004 | | | In FL_Port mode - Arbitrated Loop | 2005 +-----------+-------------+-----------------------------------------+ 2006 | E_Port | Fabric | Internal Fabric Expansion | 2007 +-----------+-------------+-----------------------------------------+ 2009 E.2 Exchange, Information Unit, Sequence, and Frame 2011 The FC 'Exchange' is a mechanism used by two FC ports to identify and 2012 manage an operation between them [18]. An Exchange is opened whenever 2013 an operation is started between two ports. The Exchange is closed 2014 when this operation ends. 2016 The FC-4 Level specifies data units for each type of protocol called 2017 'Information Unit'. Each protocol (e.g. SCSI, IP) carried by FC has a 2018 defined size for the Information Unit. Every operation must have at 2019 least one Information Unit. 2021 The FC-4 Level makes a request to FC-3 Level when it wishes it to be 2022 delivered. Currently, there are no FC-3 level defined functions, and 2023 this level simply converts the Information Unit delivery request into 2024 a 'Sequence' delivery request and passes it on to the FC-2 Level. 2025 Therefore, each FC-4 Information Unit corresponds to a FC-2 Level 2026 Sequence. 2028 The maximum data carried by a FC frame cannot exceed 2112 bytes [2]. 2029 Whenever, the Information Unit exceeds this value, the FC-2 breaks it 2030 into multiple frames and sends it in a sequence. 2032 There can be multiple Sequences within an Exchange. Sequences within 2033 an Exchange are processed sequentially. Only one Sequence is active 2034 at a time. Within an exchange information may flow in one direction 2035 only or both. If bi-directional then one of the ports has the 2036 initiative to send the next Sequence for that Exchange. Sequence 2037 Initiative can be passed between the ports on the last frame of 2038 Sequence when control is transferred. This amounts to half-duplex 2039 behavior. 2041 Ports may have more than one Exchange open at a time. Ports can 2042 multiplex between Exchanges. Exchanges are uniquely identified by 2043 Exchange IDs (X_ID). An Originator OX_ID and a Responder RX_ID 2044 uniquely identify an Exchange. 2046 E.3 Fibre Channel Header Fields 2047 The FC header as shown in the diagrams below contains routing and 2048 other control information to manage frames, sequences, and exchanges. 2049 The frame header is sent as 6 transmission words immediately 2050 following an SOF delimiter and before the data field. 2052 D_ID and S_ID: 2054 FC uses destination address routing [12], [13]. Frame routing in 2055 a point-to-point topology is trivial. 2057 For the Arbitrated Loop topology, with the destination NL_Port on 2058 the same AL, the source port must pick the destination port, 2059 determine its AL Physical Address, and "Open" the destination 2060 port. The frames must pass through other NL_Ports or the FL_Port 2061 on the loop between the source and destination, but these ports 2062 do not capture the frames. They simply repeat and transmit the 2063 frame. Either communicating port may "Close" the circuit. 2065 When the destination port is not on the same AL, the source 2066 NL_Port must open the FL_Port attached to a Fabric. Once in the 2067 Fabric, the Fabric routes the frames again to the destination. 2069 In a Fabric topology, the Fabric looks into the frame header, 2070 extracts the destination address (D_ID), searches its own routing 2071 tables, and sends the frame to the destination port along the 2072 path chosen. The process of choosing a path may be performed at 2073 each fabric element or switch until the F_Port attached to the 2074 destination N_Port is reached. 2076 Fibre Channel Frame Header, Network Header, and payload carrying IP Packet 2077 +---+----------------+----------------+----------------+--------------+ 2078 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 2079 +---+----------------+----------------+----------------+--------------+ 2080 |0 | R_CTL | D_ID | 2081 +---+----------------+----------------+----------------+--------------+ 2082 |1 | CS_CTL | S_ID | 2083 +---+----------------+----------------+----------------+--------------+ 2084 |2 | TYPE | F_CTL | 2085 +---+----------------+----------------+----------------+--------------+ 2086 |3 | SEQ_ID | DF_CTL | SEQ_CNT | 2087 +---+----------------+----------------+----------------+--------------+ 2088 |4 | OX_ID | RX_ID | 2089 +---+--------+-------+----------------+----------------+--------------+ 2090 |5 | Parameter (Control or Relative Offset for Data ) | 2091 +---+-----------------------------------------------------------------+ 2092 |6 | NAA | Network_Dest_Address (Hi order bits) | 2093 +---+--------+-------+----------------+----------------+--------------+ 2094 |7 | Network_Dest_Address (Lo order bits) | 2095 +---+--------+-------+----------------+----------------+--------------+ 2096 |8 | NAA | Network_Src_Address (Hi order bits) | 2097 +---+--------+-------+----------------+----------------+--------------+ 2098 |9 | Network_Src_Address (Lo order bits) | 2099 +---+----------------+----------------+----------------+--------------+ 2100 |10 | DSAP | SSAP | CTRL | OUI | 2101 +---+----------------+----------------+----------------+--------------+ 2102 |11 | OUI | PID | 2103 +---+----------------+----------------+----------------+--------------+ 2104 |12 | IP Packet Data | 2105 +---+----------------+----------------+----------------+--------------+ 2106 |13 | ... | 2107 +---+----------------+----------------+----------------+--------------+ 2109 R_CTL (Routing Control) and TYPE(data structure): 2111 Frames for each FC-4 can be easily distinguished from the others 2112 at the receiving port using the R_CTL (Routing Control) and TYPE 2113 (data structure) fields in the frame header. 2115 The R_CTL has two sub-fields: Routing bits and Information 2116 category. The Routing bits sub-field has specific values that 2117 mean FC-4 data follows and the Information Category tells the 2118 receiver the "Type" of data contained in the frame. The R_CTL 2119 and TYPE code points are shown in the diagrams. 2121 Other Header fields: 2123 F_CTL (Frame Control) and SEQ_ID (Sequence Identification), 2124 SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), 2125 RX_ID (Responder exchange Identifier), and Parameter fields are 2126 used to manage the contents of a frame, and mark information 2127 exchange boundaries for the destination port. 2129 F_CTL(Frame Control): 2131 The FC_CTL field is a 3-byte field that contains information 2132 relating to the frame content. Most of the other frame header 2133 fields are used for frame identification. Among other things, 2134 bits in this field indicate the first sequence, last sequence, or 2135 end sequence. Sequence Initiative bit is used to pass control of 2136 the next sequence in the exchange to the recipient. 2138 SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count): 2140 This is used to uniquely identify sequences within an Exchange. 2141 The uniquely identifies any active sequence. 2142 SEQ_CNT is used to uniquely identify frames within a Sequence to 2143 assure sequentiality of frame reception, and to allow unique 2144 correlation of link control frames with their related data 2145 frames. 2147 Originator Exchange Identifier (OX_ID) and Responder Exchange 2148 Identifier (RX_ID): 2150 The OX_ID value provides association of frames with specific 2151 Exchanges originating at a particular N_Port. The RX_ID field 2152 provides the same function that the OX_ID provides for the 2153 Exchange Originator. The OX_ID is meaningful on the Exchange 2154 Originator, and the RX_ID is meaningful on the Responder. 2156 DF_CTL (Data Field Control): 2158 The DF_CTL field specifies the presence or absence of optional 2159 headers between the Frame header and Frame Payload 2161 PARAMETER: 2163 The Parameter field has two meanings, depending on Frame type. 2164 For Link Control Frames, the Parameter field indicates the 2165 specific type of Link Control frame. For Data frames, this 2166 field contains the Relative Offset value. This specifies an 2167 offset from an Upper Layer Protocol buffer from a base address. 2169 E.4 Code Points for FC Frame 2171 E.4.1 Code Point with IP and ARP Packets 2173 The Code Points for FC Frames with IP and ARP Packets are very 2174 similar with the exception of PID value in Word 11 which is set to 2175 0x08-00 for IP and 0x08-06 for ARP. Also, the Network Header appears 2176 only in the first logical frame of a FC Sequence carrying IP. In the 2177 case, where FC frames carry ARP packets it is always present because 2178 these are single frame sequences. 2180 Code Points for FC Frame with IP packet Data 2181 +---+----------------+----------------+----------------+------------+ 2182 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 2183 +---+----------------+----------------+----------------+------------+ 2184 | 0 | 0x04 | D_ID | 2185 +---+----------------+----------------+----------------+------------+ 2186 | 1 | 0x00 | S_ID | 2187 +---+----------------+----------------+----------------+------------+ 2188 | 2 | 0x05 | F_CTL | 2189 +---+----------------+----------------+----------------+------------+ 2190 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 2191 +---+----------------+----------------+----------------+------------+ 2192 | 4 | OX_ID | RX_ID | 2193 +---+----------------+----------------+----------------+------------+ 2194 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 2195 +---+------+--------------------------------------------------------+ 2196 | 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) | 2197 +---+------+---------+----------------+----------------+------------+ 2198 | 7 | Dest. MAC (Lo order bits) | 2199 +---+------+----------+----------------+----------------------------+ 2200 | 8 | 0001 | 0x000 | Src. MAC (Hi order bits) | 2201 +---+------+---------+----------------+----------------+------------+ 2202 | 9 | Src. MAC (Lo order bits) | 2203 +---+----------------+----------------+----------------+------------+ 2204 |10 | 0xAA | 0xAA | 0x03 | 0x00 | 2205 +---+----------------+----------------+----------------+------------+ 2206 |11 | 0x00-00 | 0x08-00 | 2207 +---+----------------+----------------+----------------+------------+ 2208 |12 | IP Packet Data | 2209 +---+----------------+----------------+----------------+------------+ 2210 |13 | ... | 2211 +---+----------------+----------------+----------------+------------+ 2213 Code Points for FC Frame with ARP packet Data 2214 +---+----------------+----------------+----------------+------------+ 2215 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 2216 +---+----------------+----------------+----------------+------------+ 2217 | 0 | 0x04 | D_ID | 2218 +---+----------------+----------------+----------------+------------+ 2219 | 1 | 0x00 | S_ID | 2220 +---+----------------+----------------+----------------+------------+ 2221 | 2 | 0x05 | F_CTL | 2222 +---+----------------+----------------+----------------+------------+ 2223 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 2224 +---+----------------+----------------+----------------+------------+ 2225 | 4 | OX_ID | RX_ID | 2226 +---+----------------+----------------+----------------+------------+ 2227 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 2228 +---+------+--------------------------------------------------------+ 2229 | 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) | 2230 +---+------+---------+----------------+----------------+------------+ 2231 | 7 | Dest. MAC (Lo order bits) | 2232 +---+------+----------+----------------+----------------------------+ 2233 | 8 | 0001 | 0x000 | Src. MAC (Hi order bits) | 2234 +---+------+---------+----------------+----------------+------------+ 2235 | 9 | Src. MAC (Lo order bits) | 2236 +---+----------------+----------------+----------------+------------+ 2237 |10 | 0xAA | 0xAA | 0x03 | 0x00 | 2238 +---+----------------+----------------+----------------+------------+ 2239 |11 | 0x00-00 | 0x08-06 | 2240 +---+----------------+----------------+----------------+------------+ 2241 |12 | ARP Packet Data | 2242 +---+----------------+----------------+----------------+------------+ 2243 |13| ... | 2244 +---+----------------+----------------+----------------+------------+ 2246 The Code Points for a FARP-REQ for a specific Match Address Code 2247 Point MATCH_WW_PN_NN ( b'011') is shown below. In particular, note 2248 the IP addresses field of the Requester set to a valid address and 2249 that of the responder set to '0'. Note also the setting of the D_ID 2250 address and the Port_ID of the Responder. 2252 The corresponding code point for a FARP-REPLY is also shown below. 2253 In particular, note that the setting of the Port_ID of Responder and 2254 the IP address setting of the Responder. 2256 E.4.2 Code Points with FARP Command 2257 Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN 2258 +---+----------------+----------------+----------------+------------+ 2259 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 2260 +---+----------------+----------------+----------------+------------+ 2261 | 0 | 0x04 | D_ID = | 2262 | | | 0xFF 0xFF 0xFF | 2263 +---+----------------+----------------+----------------+------------+ 2264 | 1 | 0x00 | S_ID | 2265 +---+----------------+----------------+----------------+------------+ 2266 | 2 | 0x05 | F_CTL | 2267 +---+----------------+----------------+----------------+------------+ 2268 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 2269 +---+----------------+----------------+----------------+------------+ 2270 | 4 | OX_ID | RX_ID | 2271 +---+----------------+----------------+----------------+------------+ 2272 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 2273 +---+----------------+----------------+----------------+------------+ 2274 | 6 | 0x54 | 0x00 | 0x00 | 0x00 | 2275 +---+----------------+----------------+----------------+------------+ 2276 | 7 | Port_ID of Requester = S_ID |Match Addr. | 2277 | | |Code Points | 2278 | | | xxxxx011 | 2279 +---+----------------+----------------+----------------+------------+ 2280 | 8 | Port_ID of Responder = |Responder | 2281 | | 0x00 0x00 0x00 |Flags | 2282 +---+----------------+----------------+----------------+------------+ 2283 | 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)| 2284 +---+------+---------+----------------+----------------+------------+ 2285 |10 | WW_PN Src. MAC (Lo order bits) | 2286 +---+------+----------+---------------+-----------------------------+ 2287 |11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)| 2288 +---+------+---------+----------------+----------------+------------+ 2289 |12 | WW_NN Src. MAC (Lo order bits) | 2290 +---+----------------+----------------+----------------+------------+ 2291 |13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)| 2292 +---+------+---------+----------------+----------------+------------+ 2293 |14 | WW_PN Dest. MAC (Lo order bits) | 2294 +---+------+----------+---------------+-----------------------------+ 2295 |15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)| 2296 +---+------+---------+----------------+----------------+------------+ 2297 |16 | WW_NN Dest. MAC (Lo order bits) | 2298 +---+----------------+----------------+----------------+------------+ 2299 |17 | 0x00-00-00-00 | 2300 +--------------------+----------------+---------+-------------------+ 2301 |18 | 0x00-00-00-00 | 2302 +--------------------+----------------+---------+-------------------+ 2303 |19 | 0x00-00-00-00 | 2304 +--------------------+----------------+---------+-------------------+ 2305 |20 | set to a valid IPv4 Address by Requester | 2306 +--------------------+----------------+---------+-------------------+ 2307 |21 | 0x00-00-00-00 | 2308 +--------------------+----------------+---------+-------------------+ 2309 |22 | 0x00-00-00-00 | 2310 +--------------------+----------------+---------+-------------------+ 2311 |23 | 0x00-00-00-00 | 2312 +--------------------+----------------+---------+-------------------+ 2313 | | 0x00-00-00-00 | 2314 |24 | set to a valid IPv4 Address of Responder if available | 2315 +--------------------+----------------+---------+-------------------+ 2317 Code Points for FC Frame with FARP-REPLY Command 2319 +---+----------------+----------------+----------------+------------+ 2320 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 2321 +---+----------------+----------------+----------------+------------+ 2322 | 0 | 0x04 | D_ID | 2323 +---+----------------+----------------+----------------+------------+ 2324 | 1 | 0x00 | S_ID | 2325 +---+----------------+----------------+----------------+------------+ 2326 | 2 | 0x05 | F_CTL | 2327 +---+----------------+----------------+----------------+------------+ 2328 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 2329 +---+----------------+----------------+----------------+------------+ 2330 | 4 | OX_ID | RX_ID | 2331 +---+----------------+----------------+----------------+------------+ 2332 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 2333 +---+----------------+----------------+----------------+------------+ 2334 | 6 | 0x55 | 0x00 | 0x00 | 0x00 | 2335 +---+----------------+----------------+----------------+------------+ 2336 | 7 | Port_ID of Requester = D_ID | xxxxx011 | 2337 +---+----------------+----------------+----------------+------------+ 2338 | 8 | Port_ID of Responder = S_ID |Resp. Flag | 2339 +---+----------------+----------------+----------------+------------+ 2340 | 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)| 2341 +---+------+---------+----------------+----------------+------------+ 2342 |10 | WW_PN Src. MAC (Lo order bits) | 2343 +---+------+----------+---------------+-----------------------------+ 2344 |11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)| 2345 +---+------+---------+----------------+----------------+------------+ 2346 |12 | WW_NN Src. MAC (Lo order bits) | 2347 +---+----------------+----------------+----------------+------------+ 2348 |13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)| 2349 +---+------+---------+----------------+----------------+------------+ 2350 |14 | WW_PN Dest. MAC (Lo order bits) | 2351 +---+------+----------+---------------+-----------------------------+ 2352 |15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)| 2353 +---+------+---------+----------------+----------------+------------+ 2354 |16 | WW_NN Dest. MAC (Lo order bits) | 2355 +---+----------------+----------------+----------------+------------+ 2356 |17 | 0x00-00-00-00 | 2357 +--------------------+----------------+---------+-------------------+ 2358 |18 | 0x00-00-00-00 | 2359 +--------------------+----------------+---------+-------------------+ 2360 |19 | 0x00-00-00-00 | 2361 +--------------------+----------------+---------+-------------------+ 2362 |20 | set to a valid IPv4 Address by Requester | 2363 +--------------------+----------------+---------+-------------------+ 2364 |21 | 0x00-00-00-00 | 2365 +--------------------+----------------+---------+-------------------+ 2366 |22 | 0x00-00-00-00 | 2367 +--------------------+----------------+---------+-------------------+ 2368 |23 | 0x00-00-00-00 | 2369 +--------------------+----------------+---------+-------------------+ 2370 |24 | set to a valid IPv4 Address by Responder | 2371 +--------------------+----------------+---------+-------------------+ 2373 APPENDIX F: Fibre Channel Protocol Considerations 2375 F.1 RELIABILITY IN CLASS 3 2377 Problem: Sequence ID reuse in Class 3 can conceivably result in 2378 missing frame aliasing, which could result in delivery of corrupted 2379 (incorrectly- assembled) data, with no corresponding detection at the 2380 FC level. 2382 Prevention: This specification requires one of the following methods 2383 if Class 3 is used. 2385 - Continuously increasing Sequence Count (new Login Bit) - both 2386 sides must set When an N_Port sets the PLOGI login bit for 2387 continuously increasing SEQ_CNT, it is guaranteeing that it 2388 will transmit all frames within an exchange using a 2389 continuously increasing SEQ_CNT (see description in Section 2390 B.1 below). 2392 - After using all SEQ_IDs (0-255) once, must start a new 2393 Exchange. It is recommended that a minimum of 4 Exchanges be 2394 used before an OX_ID can be reused. 2396 - Note: If an implementation is not checking the OX_ID when 2397 reassembling sequences, the problem can still occur. Cycling 2398 through some number of SEQ_IDs, then jumping to a new exchange 2399 does not solve the problem. SEQ_IDs must still be unique 2400 between two N_Ports, even across exchanges. 2402 - Use only single-frame Sequences. 2404 F.2 CONTINUOUSLY INCREASING SEQ_CNT 2406 This method allows the recipient to check incoming frames, knowing 2407 exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not 2408 repeat for 65,536 frames, the aliasing problem is significantly 2409 reduced. 2411 A login bit (PLOGI) is used to indicate that a device always uses a 2412 continuously increasing SEQ_CNT, even across transfers of sequence 2413 initiative. This bit is necessary for interoperability with some 2414 devices, and it provides other benefits as well. 2416 In the FC-PH-3 [11], the following is supported: 2418 Word 1, bit 17 - SEQ_CNT (S) 2419 0 = Normal FC-PH rules apply 2420 1 = Continuously Increasing SEQ_CNT 2422 Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will 2423 transmit all frames within an exchange using a continuously 2424 increasing SEQ_CNT. Each exchange shall start with SEQ_CNT = 0 in the 2425 first frame, and every frame transmitted after that shall increment 2426 the previous SEQ_CNT by one, even across transfers of sequence 2427 initiative. Any frames received from the other N_Port in the exchange 2428 shall have no effect on the transmitted SEQ_CNT. 2430 Appendix G. Acronyms and Glossary of FC Terms 2432 It is assumed that the reader is familiar with the terms and acronyms 2433 used in the FC protocol specification [2]. The following is provided 2434 for easy reference. 2436 First Frame: The frame that contains the SOFi field. This means a 2437 logical first and may not necessarily be the first frame temporally 2438 received in a sequence. 2440 Code Point: The coded bit pattern associated with control fields in 2441 frames or packets. 2443 PDU: Protocol Data Unit 2445 ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for 2446 aborting an exchange based on the ABTS recipient setting the 2447 Last_Sequence bit in the BA_ACC ELS to the ABTS 2449 ADISC: Discover Address. An ELS for discovering the Hard Addresses 2450 (the 24 bit NL_Port Identifier) of N_Ports 2452 D_ID: Destination ID 2454 ES: End sequence. This FCTL bit in the FC header indicates this frame 2455 is the last frame of the sequence. 2457 FAN: Fabric Address Notification. An ELS sent by the fabric to all 2458 known previously logged in ports following an initialization event. 2460 FLOGI: Fabric Login. 2462 LIP: Loop Initialization. A primitive sequence used by a port to 2463 detect if it is part of a loop or to recover from certain loop 2464 errors. 2466 Link: Two unidirectional paths flowing in opposite directions and 2467 connecting two Ports within adjacent Nodes. 2469 LOGO: Logout. 2471 LR: Link reset. A primitive sequence transmitted by a port to 2472 initiate the link reset protocol or to recover from a link timeout. 2474 LS: Last sequence of Exchange. This FCTL bit in the FC header 2475 indicates the sequence is the last sequence of the exchange. 2477 Network Address Authority: A 4-bit field specified in Network Headers 2478 that distinguishes between various name registration authorities that 2479 may be used to identify the WW_PN and the WW_NN. NAA=b'0001' 2480 indicates IEEE-48-bit MAC addresses 2481 Node: A collection of one or more Ports identified by a unique World 2482 Wide Node Name (WW Node Name). 2484 NOS: Not Operational. A primitive sequence transmitted to indicate 2485 that the port transmitting this sequence has detected a link failure 2486 or is offline, waiting for OLS to be received. 2488 OLS: Off line. A primitive sequence transmitted to indicate that the 2489 port transmitting this sequence is either initiating the link 2490 initialization protocol, receiving and recognizing NOS, or entering 2491 the offline state. 2493 PDISC: Discover Port. An ELS for exchanging Service Parameters 2494 without affecting login state. 2496 Primitive Sequence: A primitive sequence is an Ordered Set that is 2497 transmitted repeatedly and continuously. 2499 Private Loop Device: A device that does not attempt fabric login 2500 (FLOGI) and usually adheres to PLDA. The Area and Domain components 2501 of the NL_Port ID must be 0x0000. These devices cannot communicate 2502 with any port not in the local loop. 2504 Public Loop Device: A device whose Area and Domain components of the 2505 NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the 2506 device must attempt to open AL_PA 0x00 and attempt FLOGI. These 2507 devices communicate with devices on the local loop as well as devices 2508 on the other side of a Fabric. 2510 Port: The transmitter, receiver and associated logic at either end of 2511 a link within a Node. There may be multiple Ports per Node. Each Port 2512 is identified by a unique Port_ID, which is volatile, and a unique 2513 World Wide Port Name (WW Port Name), which is unchangeable. In this 2514 document, the term "port" may be used interchangeably with NL_Port or 2515 N_Port. 2517 Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. 2518 In a Fibre Channel frame header, the Port_ID is referred to as S_ID 2519 (Source ID) to identify the port originating a frame, and D_ID to 2520 identify the destination port. The Port_ID of a given port is 2521 volatile (changeable). The mechanisms through which a Port_ID may 2522 change in a Fibre Channel topology are outside the scope of this 2523 document. 2525 PLOGI: Port Login. 2527 SI: Sequence Initiative 2529 World Wide Port_Name (WW_PN): Fibre Channel requires each Port to 2530 have an unchangeable WW_PN. Fibre Channel specifies a Network Address 2531 Authority (NAA) to distinguish between the various name registration 2532 authorities that may be used to identify the WW_PN. A 4-bit NAA 2533 identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address 2534 together make this a 64-bit field. 2536 World Wide Node_Name (WW_NN): Fibre Channel identifies each Node with 2537 a unchangeable WW_NN. In a single port Node, the WW_NN and the WW_PN 2538 may be identical. 2540 [draft-ietf-ipfc-fibre-channel-04.txt] [This INTERNET DRAFT expires 2541 on July 15, 1999]