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