idnits 2.17.1 draft-ietf-ipfc-fibre-channel-01.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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 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 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 272 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 50 has weird spacing: '... most of th...' == Line 63 has weird spacing: '...promote inter...' == Line 66 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: 13 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 Mar 18, 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 1. Introduction 41 FC is a gigabit speed networking technology primarily used for 42 Storage Area Networking (SAN). FC is standardized under American 43 National Standards Institute (ANSI)and has specified a number of 44 documents describing its protocols, operations, and services. 46 Need: 48 Currently, Fibre Channel is predominantly used for communication 49 between storage devices and servers using the SCSI protocol, with 50 most of the servers still communicating with each other over LANs. 51 Although, the Fibre Channel standard [3] has architecturally defined 52 support for IP encapsulation and address resolution, it is 53 inadequately specified. ([3] prohibits broadcasts thus loops are not 54 covered; [10] has no support for Class 3) 55 This has lead to a nonstandard way of using IP over FC in the past. 56 Once, such a standard method is completely specified, servers can 57 directly communicate with each other using IP over FC, possibly 58 boosting performance in Server host-to-host communications. This 59 technique will be especially useful in a Clustering Application. 61 Objective: 63 The major objective of this specification is to promote inter- 64 operable implementations of IP over Fibre Channel. This 65 specification describes a method for encapsulating IPv4 and Address 66 Resolution Protocol (ARP) packets over Fibre Channel. This 67 specification accommodates any FC topology (loop, fabric, or point- 68 to-point) and any FC class of service (1, 2 or 3). Use of IEEE 802.2 69 LLC/SNAP encapsulation for IP and ARP as specified in this document 70 shall not preclude the use of same encapsulation technique for other 71 protocol stacks (e.g. IPX, AppleTalk). 73 Organization: 75 Section 2 states the problem that is solved in this specification. 76 Section 3 describes the techniques used for encapsulating IP and ARP 77 packets in a FC sequence. Section 4 discusses ARP (IP address to MAC 78 address) and the required mappings and operation. Section 5 79 discusses the FC Layer mappings (MAC address to Port_ID). Section 6 80 provides a discussion on validation of the FC-layer mapping for the 81 different FC topologies. Section 7 describes the "Exchange" 82 Management in FC. Section 8 is a summary section and provides a quick 83 summary of the FC header settings, FC Link Service Commands, and a 84 summarized reference to features supported in ARP, FC Sequences, FC 85 Exchanges, and FC Login Parameters. 87 Appendix A provides a brief overview of the FC Protocols and Networks 88 along with a list of acronyms and a glossary of FC Terms used in this 89 specification. Appendix B addresses reliability in Class 3. 91 2. Problem Statement 93 This draft addresses two problems: 94 - A sequence format definition and encapsulation mechanism for IP 95 and ARP packets over FC 96 - A mechanism(s) Address Resolution 98 As noted earlier, the existing FC Standards [3], [10] are inadequate. 99 A solution to both problems has been proposed by the Fibre Channel 100 Association (FCA)[1]. FCA is a industry consortium of Fibre Channel 101 vendor companies and not a standards body. This draft specification 102 is largely based on the proposed solution in [1] and is an attempt to 103 provide a standardized specification addressing both the above stated 104 problems. 106 3. IP/ARP Encapsulation 108 3.1 FC Frame Format 109 All FC frames have a standard format much like LAN 802.x protocols. 110 (See Appendix A for Fibre Channel related Acronyms and Glossary of 111 Terms.) However, the exact size of each frame varies depending on the 112 sizes of the variable fields. The FC frame structure is shown in 113 Fig. 1. 115 +-------+--------+-----------+----//-------+-----+-----+ 116 | SOF |Frame |Optional | Payload |CRC | EOF | 117 | (4B) |Header |Header | |(4B) |(4B) | 118 | |(24B) |<----------------------->| | | 119 | | | (0-2112B) | | | 120 +-------+--------+-----------+----//-------+-----+-----+ 122 Fig. 1 FC Frame Format 124 The Start of Frame (SOF) and End of Frame (EOF) are both 4 bytes long 125 and act as frame delimiters. 127 The CRC is 4 bytes long and uses the same 32-bit polynomial used in 128 FDDI and is specified in ANSI X3.139 Fiber Distributed Data 129 Interface. 131 The Frame Header is 24 bytes long and has several fields associated 132 with identification and control of the payload. The values and 133 options for the fields that are relevant to the IP and ARP payloads 134 will be discussed later. 136 A FC Optional Header allows up to 4 optional header fields: 138 - An Expiration Security Header (16 bytes) 139 - Network (16 bytes) 140 - Association (32 bytes) 141 - Device (up to 64 bytes). 143 The IP and ARP FC sequences are required to carry the Network_Header 144 optional header field which is 16 bytes long. Other types of optional 145 headers are prohibited. The use of the Network_Header for the IP and 146 ARP payload encapsulation is described below. 148 In FC, an application level payload is called a Sequence. Typically, 149 a Sequence consists of more than one frame. Larger user data is 150 segmented and reassembled using two methods: Sequence Count and 151 Relative Offset. Use of Sequence Count is straight forward and data 152 blocks are sent using frames with increasing sequence counts (modulo 153 16). With Relative Offset, frames could temporally arrive out of 154 order. 156 When IP and ARP form the FC payload then only the First Frame of the 157 logical Sequence shall include the FC Network_Header. (Care should 158 exercised when this is the case. Note that the physical temporal 159 ordering of the frames can be different as a result of travesing 160 through a "Fabric".) Fig. 2 shows the logical First Frame and 161 logical subsequent frames 162 First Frame of a Logical FC Sequence 163 ---+------------+---------------------------+----------//----------+--- 164 | FC Header | FC Network Header | FC Sequence Data | 165 ---+------------+---------------------------+---------//-----------+--- 167 Subsequent Frames of a Logical FC Sequence 168 --+-----------+----------//------+-- 169 | FC Header | FC Sequence Data | 170 --+-----------+----------//------+-- 172 Fig. 2 FC Network Header in a Frame Sequence 174 The SOF, CRC, EOF control fields and other optional headers have been 175 omitted in the figure for clarity. 177 3.2 MTU 179 The Maximum Transmission Unit (MTU) for IP is defined as the length 180 of the IP packet, including IP headers. The theoretical maximum size 181 of an IP Packet is 65,535 bytes. In FC-4 the transmission unit is a 182 "Information Unit" and not frames. An N_Port may transmit an 183 Information Unit using multiple frames. The receiving N_Port will 184 assemble the frames to reconstruct the sent Information Unit. The 185 size of a single Information Unit is limited to 2^32-1, which is very 186 large. However, restricting the IP over FC MTU helps in buffer 187 resource allocation at N_Ports. A MTU of 65,280 bytes allows for up 188 to 256 bytes of overhead. The IEEE 802.2 LLC/SNAP headers requires 8 189 bytes, leaving the rest 248 bytes for future uses. 191 There shall be a one-to-one mapping between an IP packet and a FC 192 sequence. In other words, one IP packet shall always map to only one 193 FC Sequence. 195 Note that, although the FC physical frame MTU is limited to 2112 196 bytes, it is hidden from IP and does not affect the IP MTU at FC-4. 198 3.3 FC Port and Node Network Addresses 200 FC devices are identified by Nodes and Ports. A Node is a collection 201 of one or more Ports identified by a unique nonvolatile 64-bit World 202 Wide Node name (WW_NN). Each Port in a node, is identified with a 203 unique nonvolatile 64-bit World Wide Port name (WW_PN), and a 204 volatile Port_ID. 206 Port_ID are 24-bits. In a FC frame header, the Port_ID is referred to 207 as S_ID (Source ID) to identify the port originating a frame, and 208 D_ID to identify the destination port. The Port_ID of a given port is 209 volatile. (The mechanism(s) by which a Port_ID may change in a FC 210 topology is outside the scope of this document.) 212 FC specifies a Network Address Authority (NAA) to distinguish between 213 the various name registration authorities that may be used to 214 identify the WW_PN and the WW_NN. A 4-bit NAA identifier, 12-bit 215 field set to 0x000 and an IEEE 48-bit MAC address together make the 216 64-bit WW_NN or the WW_PN addresses [2]. In a single port Node, the 217 WW_NN and the WW_PN may be identical. 219 The WW_PN names of the source and destinations are carried in the FC 220 Network Header. The format of the FC Network Header is shown in Fig. 221 3 and defined in the FC standards [2]. The Network header is 222 normally optional in FC but mandatory in this specification. The 4 223 most significant bits in each address denotes the Network Address 224 Authority (NAA) type. In this specification, the source and 225 destination NAA binary pattern '0001' indicates the IEEE-48 bit MAC 226 address and is the only code point that is allowed. This NAA field 227 value allows FC networks to be bridged with other FC networks or 228 traditional LANs. The Source (Destination) MAC address occupies the 229 lower 48 bits of the Network_Source_Address (Network_Dest_Address), 230 and the upper 12 bits are set to 0x000. 232 +--------+---------------------------------------+ 233 | D_NAA |Network_Dest_Address (High-order bits) | 234 |(4 bits)| (28 bits) | 235 +--------+---------------------------------------+ 236 | Network_Dest_Address (Low-order bits) | 237 | (32 bits) | 238 +--------+---------------------------------------+ 239 | S_NAA |Network_Source_Address(High-order bits)| 240 |(4 bits)| (28 bits) | 241 +--------+---------------------------------------+ 242 | Network_Source_Address (Low-order bit) | 243 | (32 bits) | 244 +--------+---------------------------------------+ 246 Fig. 3 Format of the Network Header Field 248 3.4 FC Payload Format 250 The payload of an FC sequence carrying an IP packet shall use the 251 format shown in Fig. 4. Fig. 5 shows the format when the payload is 252 an ARP packet. However, both formats use the 8-byte LLC/SNAP header. 254 +-----------------+-----//----------+-------------//------------+ 255 | LLC/SNAP Header | IP Header | IP Data | 256 | (8 bytes) | (20 bytes min.) | (65280 -IP Header) bytes | 257 +-----------------+-----//----------+-------------//------------+ 259 Fig. 4 Format of FC Sequence Payload carrying IP 261 +-----------------+-------------------+ 262 | LLC/SNAP Header | ARP Packet | 263 | (8 bytes) | (28 bytes) | 264 +-----------------+-------------------+ 266 Fig. 5 Format of FC Sequence Payload carrying ARP 268 As noted earlier, since FC frames belonging to the same Sequence can 269 be delivered out of order over a Fabric, the IP Header must appear in 270 the frame that has relative offset of 0. 272 A Logical Link Control (LLC) field along with a Sub Network Access 273 Protocol (SNAP) field is a method used to identify routed and bridged 274 non-OSI protocol PDUs and is defined in IEEE 802.2 and applied to IP 275 in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless 276 mode), the LLC header is 3-bytes long and consists of a 1-byte 277 Destination Service Access Point (DSAP)field, a 1-byte Source Service 278 Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 279 6. 281 +----------+----------+----------+ 282 | DSAP | SSAP | CTRL | 283 | (1 byte) | (1 byte | (1 byte) | 284 +----------+----------+----------+ 286 Fig. 6 LLC Format 288 The LLC's DSAP and SSAP values of 0xAA indicate that a IEEE 802.2 289 SNAP header follows. The LLC's CTRL value equal to 0x03 specifies 290 Unnumbered Information Command PDU. The LLC header value shall be 291 0xAA-AA-03. Other values of DSAP/SSAP indicate support for other 292 protcols but are prohibited in this specification. 294 The SNAP header is 5 bytes long and consists of a 3-byte 295 Organizationally Unique Identifier (OUI) field and a 2-byte Protocol 296 Identifier as shown in Fig. 7 298 +------+------+-------+------+------+ 299 | OUI | PID | 300 | ( 3 bytes) | (2 bytes) | 301 +------+------+-------+------+------+ 303 Fig. 7 SNAP Format 305 SNAP was invented to "encapsulate" LAN frames within the payload. 306 The SNAP OUI value 0x00-00-00 specifies that the PID is an EtherType 307 (i.e., routed non-OSI protocol). An OUI value of 0x00-80-C2 indicates 308 Bridged Protocols. 310 When the OUI value equals 0x00-00-00, the SNAP PID value of 0x08-00 311 indicates IP and a SNAP PID value of 0x08-06 indicates ARP. The 312 complete LLC/SNAP header is shown in Fig. 8. 314 +----------+----------+----------+-------+-------+-------+-------+------+ 315 | DSAP | SSAP | CTRL | OUI | PID | 316 | (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes | 317 +----------+----------+----------+-------+-------+-------+-------+------+ 319 Fig. 8 LLC/SNAP Header 321 3.5 ARP Packet Format 323 The format of the encapsulated ARP packet is based on [9] and is 324 shown in Fig. 9. 326 The 'HW Type' field shall be set to 0x00-01 328 Note: Technically, the correct HW Type value should be set to 0x00-06 329 according to RFC 1700 indicating IEEE 802 networks. However, as a 330 practical matter a HW Type value of 0x00-06 is known to cause 331 rejections from some Ethernet end stations when FC is bridged to 332 Ethernet. Translational bridges are normally expected to change this 333 field from Type 6 to 1 and vice versa under these configurations but 334 many do not. It is because of this reason the Type Code is set to 1 335 rather than 6. However, both HW Type values of 0x00-01 and 0x00-06 336 shall be accepted. 338 The 'Protocol' field shall be set to 0x08-00 indicating IP protocol. 340 The 'HW Addr Length' field shall be set to 0x06 indicating 6 bytes of 341 HW address. 343 The 'Protocol Addr Length' field shall be set to 0x04 indicating 4 344 bytes of IP address. 346 The 'Operation' Code field shall be either 0x00-01 for Request or 347 0x00- 02 for Reply. 349 +-------------------------+ 350 | HW Type | 2 bytes 351 +-------------------------+ 352 | Protocol | 2 bytes 353 +-------------------------+ 354 | HW Addr Length | 1 byte 355 +-------------------------+ 356 | Protocol Addr Length | 1 byte 357 +-------------------------+ 358 | Op Code | 2 bytes 359 +-------------------------+ 360 | HW Addr of Sender | 6 bytes 361 +-------------------------+ 362 | Protocol Addr of Sender | 4 bytes 363 +-------------------------+ 364 | HW Addr of Target | 6 bytes 365 +-------------------------+ 366 | Protocol Addr of Target | 4 bytes 367 +-------------------------+ 368 Total 28 bytes 370 Fig. 9 ARP Packet Format 372 The 'HW Addr of Sender' field shall be the 6 byte IEEE MAC address of 373 the sender. 375 The 'Protocol Addr of Sender' field shall be the 4 byte IP address of 376 the sender. 378 The 'HW Addr of Target' field shall be set to zero if the 'Operation 379 Code' field is set to 1. Otherwise, it shall be set to the 6 byte 380 IEEE MAC address of the original sender of the ARP request. 382 The 'Protocol Addr of Target' field shall be set to the 4 byte IP 383 address of the target. 385 The ARP packet is 28 bytes long in this particular application. The 386 difference between an ARP Request Packet and an ARP Reply Packet is 387 given below: 389 1. ARP Request packet: 'Operation' Code field = 0x00-01 and the 'HW 390 Addr of Target' is set to 0x00-00-00-00-00-00. 392 2. ARP Reply packet: 'Operation' Code field = 0x00-02 and the 'HW 393 Addr of Target' is appropriately set to the extracted 'HW Addr 394 of Sender' field from the ARP Request packet; similarly, the 395 'Protocol Addr of Target' is set to the extracted 'Protocol 396 Addr of Sender' field from the ARP Request packet 398 An ARP Request message is defined as a FC broadcast sequence carrying 399 the ARP Request packet. The exact mechanism used to broadcast a FC 400 sequence depends on the topology and will be discussed in the next 401 section. Compliant ARP broadcast messages shall include Network 402 Headers. 404 An ARP Reply message is defined as an ARP Reply packet encapsulated 405 in a FC sequence. Compliant ARP Reply messages shall include Network 406 Headers. 408 4. Address Resolution 410 4.1 Problem Description 412 Address Resolution is concerned with associating IP addresses with FC 413 Port addresses. As described earlier, FC device ports have two 414 addresses: 415 - a non-volatile unique 64-bit address called World Wide Port_Name 416 (WW_PN) 418 - a volatile 24-bit address called a Port_ID (see Appendix A for a 419 definition of Port_ID) 421 The Address Resolution mechanism therefore will need two levels of 422 mapping: 424 1. A mapping from IP address to the WW_PN address(i.e., IEEE 425 48-bit MAC address) 427 2. A mapping from WW_PN to the Port_ID 429 The address resolution problem is compounded by the fact that the 430 Port_ID is volatile and the second mapping has to be validated before 431 use. Moreover, this validation process can be different depending on 432 the FC network topology used. 434 Architecturally, the first level of mapping and control operation is 435 handled by the ARP layer, and the second level of mapping and control 436 by the FC layer. 438 4.2 ARP Layer Mapping and Operation 440 Whenever a source FC port with a designated IP address wishes to send 441 IP data to a destination FC port also with a designated IP address 442 then, the following steps are taken: 443 1. The source port shall consult its local mapping tables to 444 determine the . 445 (Since the NAA= b'0001' the WW_PN address and 48-bit MAC address 446 conceptually mean the same thing in this discussion.) 448 2. If such a mapping is found, then the source shall send the IP 449 data to the port whose WW_PN address was found in the table. 451 3. If such a mapping is not found, then the source shall send an 452 ARP broadcast message to its connected FC network in 453 anticipation of getting a reply from the correct destination 454 along with its WW_PN address. 456 4. When an ARP broadcast message is received by the destination it 457 shall generate an ARP response. Since the ARP response must be 458 addressed to a specific destination Port_ID, the FC layer 459 mapping between the MAC address and Port_ID (of the ARP Request 460 orginator) must be valid before the reply is sent. 462 4.2.1 ARP Broadcast in a Point-to-Point Topology 464 The ARP Request (Broadcast) and Reply mechansim described in 465 Section 3.5 and 4.2 still applies, although there is only one node 466 that receives this. 468 4.2.2 ARP Broadcast in a Private Loop Topology 470 In a private loop, the ARP broadcast message is sent using the 471 broadcast method specified in the FC-AL [7]standard. 473 1. The source port shall first send an Open Broadcast 474 Replicate primitive (OPN(fr))Signal forcing all the ports in 475 the loop (except itself), to replicate the frames that they 476 receive while examining the frame header's Destination_ID 477 field. 479 2. The source port shall remove this OPN(fr) signal when it 480 returns to it. 482 3. The loop is now ready to receive the ARP broadcast message 483 and is sent as a broadcast sequence, that is using FC 484 frames. 486 4. The source shall now send a FC frame containing the ARP 487 Request (ARP broadcast message), as a sequence in a Class 3 488 frame with the following FC Header D_ID field and F_CTL bits 489 in the FC header set to: 491 Destination ID: D_ID = 0xFF-FF-FF 493 Sequence Initiative : SI=0 495 Last Sequence : LS=1 497 End Sequence : ES=1. 499 The above FCTL settings apply to single-frame broadcasts, 500 as used in ARP sequences. This information is provided to 501 clarify ARP Broadcast usage only, and should not be 502 interpreted as prohibiting the use of multiframe sequence 503 broadcasts for other applications. 505 5. Compliant ARP broadcast sequences shall include Network Headers 506 with destination MAC address in the Network Header set to 507 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 508 6. The destination port recognizing its IP address in the ARP 509 packet shall respond with an ARP Reply message. 511 4.2.3 ARP Broadcast in a Public Loop Topology 513 The following steps will be followed when a port is configured in a 514 public loop: 516 1. A public loop device attached to a fabric through an FL_Port 517 shall not use the OPN(fr) signal primitive. Rather, it shall 518 send the broadcast sequence to the FL_Port at AL_PA = 0x00. 520 2. A fabric shall propagate the broadcast to all other ports 521 including the FL_Port which the broadcast arrived on. This 522 includes all F_Ports, and other FL_Ports. 524 3. On each FL_Port, the fabric shall first propagate the 525 broadcast by first using the primitive signal OPNfr, in order 526 to prepare the loop to receive the broadcast sequence. 528 4. A broadcast sequence is now sent on all ports (all FL_ports, 529 F_Ports)in Class 3 frame with: 531 Destination ID : D_ID = 0xFF-FF-FF 533 Sequence Initiative : SI=0 535 Last Sequence : LS=1 537 End Sequence : ES=1. 539 5. Compliant ARP broadcast sequences shall include Network Headers 540 with destination MAC address in the Network Header set to 541 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 543 6. The destination port recognizing its IP address in the ARP 544 packet shall respond with an ARP Reply message. 546 4.2.4 ARP Operation in a Fabric Topology 548 1. Nodes directly attached to fabric do not require the OPN(fr) 549 primitive signal. 551 2. A broadcast sequence is now sent on all ports (all FL_ports, 552 F_Ports)in Class 3 frame with: 554 Destination ID : D_ID = 0xFF-FF-FF 556 Sequence Initiative : SI=0 558 Last Sequence : LS=1 560 End Sequence : ES=1. 562 3. Compliant ARP broadcast sequences shall include Network Headers 563 with destination MAC address in the Network Header set to 564 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 566 4. The destination port recognizing its IP address in 567 the ARP packet shall respond with an ARP Reply 569 5. Mechanisms for Maintaining FC Layer Mappings 571 FC layer mapping between the WW_PN and the Port_ID is independent of 572 the ARP mechanism and is more closely associated with the details of 573 the FC protocols. Two main mechanisms - Name Server and FARP that may 574 be used to create and maintain WW_PN to Port_ID tables are described 575 here. Other less formal mechanisms are described in Appendix C. The 576 preferred method is a configuration and administration issue, and may 577 be implementation-dependent. 579 5.1 Use of Name Server 581 This method is used in environments where a Name Server is 582 available[4]. 584 1. A Name Server may be referenced to resolve unmapped WW_PN 585 addresses. 587 2. Any upper layer send request for which there is not a Port_ID 588 to WW_PN mapping can trigger a query to a name server. The 589 WW_PN must be re-formatted in the 64-bit WW_PN format before 590 the query is issued. 592 3. The format of the Name Server query and response is outside 593 the scope of this document. See[4] for a typical example and 595 [14] for a Name Server implementation. 597 4. The query response from the Name Server must contain the 598 Port_ID associated with the WW_PN specified in the query. 600 5. Normal Port Login procedures follow at this point before 601 packets can be forwarded to a port. 603 5.2 FARP 605 The Fibre Channel Address Resolution Protocol (FARP) is a method 606 using ELS commands to resolve mapping in environments 607 without a Name Server. That is, when the WW_PN is known, but not the 608 D_ID and a Name Server service doesn't exist. This situation arises, 609 for instance, when Login tables entries expire. 611 The FARP Extended Link Service Broadcast Request (FARP-REQ) shall 612 resolve Port_IDs of communicating Fibre Channel devices. A FARP-REQ 613 can be used to retrieve a specific N_Port's current Port_ID given the 614 unique WW_PN and WW_NN. This is accomplished by requesting either a 615 FARP Response ELS Unicast command (FARP-RES), or by indicating that 616 the Responder N_Port shall perform a login with the FARP Requester. 617 No sequence initiatives are transferred with the FARP-REQ and the 618 FARP-RES and therefore no Reply (ACCEPT or REJECT) is sent for either 619 message. The FARP-RES is a message response sent by a higher level 620 entity at the Responder host. 622 Protocol: 624 FARP Request Sequence : FARP-REQ (ELS broadcast) 626 No Reply Sequence 628 FARP Response Sequence : FARP-RES (ELS command) 630 No Reply Sequence 632 Format: FT-1 634 Addressing: 636 - For a FARP-REQ, The S_ID designates the Requester 637 N_Port requesting addressing information. The D_ID is the 638 broadcast identifier, 0xFF-FF-FF. 640 - For a FARP-RES, the S_ID designates the N_Port ID of the 641 device matching the Responder Address Information in the FARP 642 Request. The D_ID is the N_Port ID of the device that initiated 643 the FARP request. 645 Payload: There are 2 formats of the FARP-REQ payload depending on 646 the address information carried. 648 +-----------------------------------------------------------------+ 649 | FARP-REQ Payload | 650 +-----------------------------+---------+-------------------------+ 651 | Field | Size | | 652 | |(Bytes) | Remarks | 653 +-----------------------------+---------+-------------------------+ 654 | 0x54-00-00-00 | 4 | | 655 +-----------------------------+---------+-------------------------+ 656 | Match Address Code Points | 1 | | 657 +-----------------------------+---------+-------------------------+ 658 | Port_ID of Requester | 3 | | 659 +-----------------------------+---------+-------------------------+ 660 | Responder Flags | 1 | | 661 +-----------------------------+---------+-------------------------+ 662 | Port_ID of Responder | 3 | set to 0x00-00-00 | 663 +-----------------------------+---------+-------------------------+ 664 |WW_PN of Requester (FARP-REQ)| 8 | | 665 +-----------------------------+---------+-------------------------+ 666 |WW_NN of Requester (FARP-REQ)| 8 | | 667 +-----------------------------+---------+-------------------------+ 668 |WW_PN of Responder | 8 | | 669 +-----------------------------+---------+-------------------------+ 670 |WW_NN of Responder | 8 | | 671 +-----------------------------+---------+-------------------------+ 673 +-----------------------------------------------------------------+ 674 | FARP-REQ Payload | 675 +-----------------------------+---------+-------------------------+ 676 | Field | Size | | 677 | |(Bytes) | Remarks | 678 +-----------------------------+---------+-------------------------+ 679 | 0x54-00-00-00 | 4 | | 680 +-----------------------------+---------+-------------------------+ 681 | Match Address Code Points | 1 | | 682 +-----------------------------+---------+-------------------------+ 683 | Port_ID of Requester | 3 | | 684 +-----------------------------+---------+-------------------------+ 685 | Responder Flags | 1 | | 686 +-----------------------------+---------+-------------------------+ 687 | Port_ID of Responder | 3 | set to 0x00-00-00 | 688 +-----------------------------+---------+-------------------------+ 689 |IP Address of Requester | 16 |IPv4 Add.=lower 32 bits | 690 | (FARP-REQ) | |IPv6 Add. = 128 bits | 691 +-----------------------------+---------+-------------------------+ 692 |IP Address of Responder | 16 |IPv4 Add. = lower 32 bits| 693 | | |IPv6 Add. = 128 bits | 694 +-----------------------------+---------+-------------------------+ 696 Both formats carry common fields: command code, Match Address Code 697 Point, Port_ID of Requester, Responder Flags, and Port_ID of 698 Responder. 700 The first fromat carries the WW_PN and WW_NN of both the Requester 701 and Responder while the second format carries the IP addresses of 702 Requester and Responder. Note that the NAA is implicitly assumed to 703 be defined to be equal to b'0001' indicating IEEE-48-bit MAC 704 addresses are contained in Worl Wide Port and Node Names. 706 In the first format the "WW_PN of Responder" and "WW_NN of Responder" 707 fields should be filled in with the Node and Port Names of the 708 desired Responder. 710 The Match Address Code Points define what addresses to match based on 711 these code points. 713 The Responder Flags define what Responder action if the result of the 714 Match Address Code Points is successful. 716 In the first format, the FARP-REQ Requester supplies the WW_PN of the 717 Responder, the WW_NN of the Responder, or both. 719 WW_PN in FARP is the 8-byte WW_PN of the Requester/ Responder to the 720 FARP-REQ. 722 WW_NN in FARP is the 8-byte WW_NN of the Requester/ Responder to the 723 FARP-REQ. 725 In the second format, the FARP-REQ Requester supplies either a 32-bit 726 IPv4 Address or a 128-bit IPv6 address of the Requester and 727 Responder. 729 Port_ID of Requester: is the 24-bit Port_ID used in the S_ID field of 730 the FARP-REQ header. 732 Port_ID of Responder: is the 24-bit Port_ID used in the S_ID field of 733 the FARP-RES header. 735 Responder Flags: is an 8-bit field (bits 0-7) that defines the action 736 of the Responder. This field is only valid in a FARP-REQ. 738 FARP-REQ is an ELS broadcast command. You do not have to be logged 739 in to issue a FARP request. 741 Possible Responder Actions: 743 Port Login (P_LOGI) 744 Sent to the Port Identified by " Requester Port_ID" field 745 when responder bit 0 (INIT_PLOGI) == binary '1' 747 FARP Response Sequence (FARP-RES) 749 Sent to the Port Identified by "Requester Port_ID" field 750 when responder bit 1 (INIT_FARP-RES) == binary '1' 752 Bits 2 (INIT-PLOGI) = binary '1' and Bit 3 (INIT_FARP-RES) = binary 753 '1' at the same time is disallowed. Recipients of the FARP Request 754 ELS shall not issue a Service Reject (LS_RJT) if FARP is not 755 supported. 757 Table below indicates the action performed for each bit. If no bits 758 are set, the Responder will take no action. 759 +----------+-------------------------------------------------------+ 760 | | FARP Responder Flag | 761 +----------+--------------+----------------------------------------+ 762 | Bit | Bit Name | Action | 763 | Position | | | 764 +----------+--------------+----------------------------------------+ 765 | 0 | INIT_PLOGI | Initiate P_LOGI to the Requester | 766 +----------+--------------+----------------------------------------+ 767 | 1 | INIT_FARP-RES| Send FARP_RES message to Requester | 768 +----------+--------------+----------------------------------------+ 769 | 2 to 7 | Reserved | | 770 +----------+--------------+----------------------------------------+ 772 For each recipient of the FARP-REQ Broadcast ELS, the recipients 773 match one or more addresses based on the encoded bits of the "FARP 774 Match Address Code Points" field. This is shown in the following 775 table: 777 +------------------------------------------------------------------+ 778 | FARP Match Address Code Points | 779 +------------------------------------------------------------------+ 780 | LSBits | Bit name | Action | 781 +-----------+------------------+-----------------------------------+ 782 | 0000 | Reserved | | 783 +-----------+------------------+-----------------------------------+ 784 | 0001 | MATCH_WW_PN | Match on WW_PN of Responder | 785 +-----------+------------------+-----------------------------------+ 786 | 0010 | MATCH_WW_NN | Match on WW_NN of Responder | 787 +-----------+------------------+-----------------------------------+ 788 | 0011 | MATCH_WW_PN & | Match on both WW_PN and | 789 | | MATCH_WW_NN | WW_NN of Responder | 790 +-----------+------------------+-----------------------------------+ 791 | 0100 to | Reserved | | 792 | 1000 | | | 793 +-----------+------------------+-----------------------------------+ 794 | 1001 | MATCH_IPv4 | Match on IPv4 Address of Responder| 795 +-----------+------------------+-----------------------------------+ 796 | 1010 | MATCH_IPv6 | Match on IPv6 Address of Responder| 797 +-----------+------------------+-----------------------------------+ 798 | 1011 to | Reserved | | 799 | 1111 | | | 800 +-----------+------------------+-----------------------------------+ 801 Note that bit-3 of the LSB differentiates between World_Wides 802 addresses and IP addresses. If there no matches then a silent 803 behavior from the Responder is valid. 805 FARP Response (FARP-RES) is an ELS command directed to the Port_ID of 806 the FARP-REQ Requester. You do not have to be logged in to the FARP- 807 REQ Requester to issue a FARP-RES. 809 The format of the FARP-RES payload is as follows: 811 +---------------------------------------------------------------------+ 812 | FARP-RES Payload with WW-Names | 813 +-------------------------------------+---------+---------------------+ 814 | Field | Size | Remarks | 815 | | (Bytes) | | 816 +-------------------------------------+---------+---------------------+ 817 | 0x55-00-00-00 | 4 | | 818 +-------------------------------------+---------+---------------------+ 819 | Match Address Code Points | 1 | | 820 +-------------------------------------+---------+---------------------+ 821 | Port_ID of Requester | 3 | | 822 +-------------------------------------+---------+---------------------+ 823 | Responder Flags | 1 | Not used | 824 +-------------------------------------+---------+---------------------+ 825 | Port_ID of Responder | 3 | | 826 +-------------------------------------+---------+---------------------+ 827 |WW_PN of Requester (FARP-REQ) | 8 | | 828 +-------------------------------------+---------+---------------------+ 829 |WW_NN of Requester (FARP-REQ) | 8 | | 830 +-------------------------------------+---------+---------------------+ 831 |WW_PN of Responder | 8 | | 832 +-------------------------------------+---------+---------------------+ 833 |WW_NN of Responder | 8 | | 834 +-------------------------------------+---------+---------------------+ 836 +---------------------------------------------------------------------+ 837 | FARP-RES Payload with IP Addresses | 838 +-------------------------------------+---------+---------------------+ 839 | Field | Size | | 840 | | (Bytes) | Remarks | 841 +-------------------------------------+---------+---------------------+ 842 | 0x54-00-00-00 | 4 | | 843 +-------------------------------------+---------+---------------------+ 844 | Match Address Code Points | 1 | | 845 +-------------------------------------+---------+---------------------+ 846 | Port_ID of Requester | 3 | | 847 +-------------------------------------+---------+---------------------+ 848 | Responder Flags | 1 | Not used | 849 +-------------------------------------+---------+---------------------+ 850 | Port_ID of Responder | 3 | | 851 +-------------------------------------+---------+---------------------+ 852 |IP Address of Requester (FARP-REQ) | 16 |IPv4 Add.= lo 32 bits| 853 | | |IPv6 Add.= 128 bits | 854 +-------------------------------------+---------+---------------------+ 855 |IP Address of Responder | 16 |IPv4 Add.= lo 32 bits| 856 | | |IPv6 Add.= 128 bits | 857 +-------------------------------------+---------+---------------------+ 859 6. FC layer Address Validation 861 At all times, the mapping has to be validated 862 before use. There are many events that can invalidate this mapping. 863 The following discussion addresses conditions when such a validation 864 is required. 866 6.1 General Discussion 868 After a link interruption occurs, the Port_ID of a port may change. 869 After the interruption, the Port_IDs of all other ports that have 870 previously performed PLOGI (N_Port Login) with this port may have 871 changed, and its own Port_ID may have changed. 873 Because of this, address validation is required after a LIP in a loop 874 topology [7]or after NOS/OLS in a point-to-point topology [6]. 876 Port_IDs will not change as a result of Link Reset(LR),thus address 877 validation is not required. 879 In addition to actively validating devices after a link interruption, 880 if a port receives any FC-4 data frames (other than broadcast 881 frames), from a port that is not currently logged in, then it shall 882 send an explicit Extended Link Service (ELS) Request logout (LOGO) 883 command to that port. 885 ELS commands (Requests and Replies) are used by an N_Port to solicit 886 a destination port (F_Port or N_Port) to perform some link-level 887 function or service.) The LOGO Request is used to request 888 invalidation of the service parameters and Port_ID of the recipient 889 N_Port. 891 The level of initialization and subsequent validation and recovery 892 reported to the upper (FC-4) layers is implementation-specific. 894 In general, an explicit Logout (LOGO) shall be sent whenever the FC- 895 Layer mapping between the Port_ID and WW_PN of a remote port is 896 removed. 898 The effect of power-up or re-boot on the mapping tables is outside 899 the scope of this specification. 901 6.2 FC Layer Address Validation in a Point-to-Point Topology 903 No validation is required after LR. In a point-to-point topology, 904 NOS/OLS causes implicit logout of each port and after a NOS/OLS, each 905 port must perform a PLOGI [2]. 907 6.3 FC Layer Address Validation in a Private Loop Topology 909 After a LIP, a port shall not transmit any link data to another port 910 until the address of the other port has been validated. The 911 validation consists of completing either ADISC or PDISC. (See 912 Appendix A) 914 ADISC (Address Discovery) is an ELS command for discovering the hard 915 addresses - the 24-bit identifier- of NL_Ports [5], [6]. 917 PDISC (Discover Port) is an ELS command for exchanging service 918 parameters without affecting login state [5], [6]. 920 As a requester, this specification prohibits PDISC and requires 921 ADISC. 923 As a responder, an implementation may need to respond to both ADISC 924 and PDISC for compatibility with other FC specifications. 926 If the three addresses, Port_ID, WW_PN, WW_NN, exactly match the 927 values prior to the LIP, then any active exchanges may continue. 929 If any of the three addresses have changed, then the node must be 930 explicitly logged out [4], [5]. 932 If a port's N_Port ID changes after a LIP, then all active Port-ID to 933 WW_PN mappings at this port must be explicitly logged out. 935 6.4 FC Layer Address Validation in a Public Loop Topology 937 A FAN (Fabric Address Notification) ELS command is sent by the fabric 938 to all known previously logged in ports following an initialization 939 event. Therefore, after a LIP, hosts may wait for this notification 940 to arrive or they may perform a FLOGI. 942 The WW_PN and WW_NN of the fabric FL_Port contained in the FAN ELS or 943 FLOGI response must exactly match the values before the LIP. In 944 addition, the AL_PA obtained by the port must be the same as the one 945 before the LIP. 947 If the above conditions are met, the port may resume all exchanges. 948 If not, then FLOGI (Fabric login) must be performed with the fabric 949 and all nodes must be explicitly logged out. 951 A public loop device will have to perform the private loop 952 authentication to any nodes on the local loop which have an Area + 953 Domain Address == 0x00-00-XX 955 6.5 FC Layer Address Validation in a Fabric Topology 957 No validation is required after LR (link reset). 959 After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID 960 of the port, the WW_PN of the fabric, and the WW_NN of the fabric are 961 the same as before the NOS/OLS, then the port may resume all 962 exchanges. If not, all nodes must be explicitly, logged out [2]. 964 7. Exchange Management 966 7.1 Exchange Origination 968 FC Exchanges shall be established to transfer data between ports. 969 Frames on IP exchanges shall not transfer Sequence Initiative. 971 7.2 Exchange Termination 973 With the exception of the recommendations in Appendix B, "Reliability 974 in Class 3", the mechanism for aging or expiring exchanges based on 975 activity, timeout, or other method is outside the scope of this 976 document. 978 Exchanges may be terminated by either port. 980 The Exchange Originator may terminate Exchanges by setting the LS 981 bit, following normal FC standard FC-PH [2] rules. This specification 982 prohibits the use of the NOP ELS with LS set for Exchange 983 termination. 985 Exchanges may be torn down by the Exchange Originator or Exchange 986 Responder by using the ABTS_LS protocol. The use of ABTS_LS for 987 terminating aged exchanges or error recovery is outside the scope of 988 this document. 990 The termination of IP exchanges by Logout is discouraged, since this 991 may terminate active exchanges on other FC-4s. 993 8. Summary of Supported Features 995 Note: 'Required' means the feature support is mandatory, 'Prohibited' 996 means the feature support is not allowed, 'Allowed' means the feature 997 support is optional, and 'Settable' means support is as specified in 998 the relevant standard. 1000 8.1 FC-4 Header (Note 1) 1001 +--------------------------------------------------------------------+ 1002 | Feature | Support | Notes | 1003 +--------------------------------------------------------------------+ 1004 | Type Code ( = 5) ISO8802-2 LLC/SNAP | Required | 2 | 1005 | Network Headers | Required | 3 | 1006 | Other Optional Headers | Prohibited | | 1007 +--------------------------------------------------------------------+ 1008 Notes: 1010 1. This table applies only to FC-4 related data, such as IP and 1011 ARP packets. This table does not apply to link services and 1012 other non-FC-4 sequences (PLOGI, for example) that must occur 1013 for normal operation. 1015 2. The TYPE field in the FC Header (Word 2 bits 31-24) must 1016 indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This 1017 revision of the document focuses solely on the issues related 1018 to running IP and ARP over FC. All other issues are outside 1019 the scope of this document, including full support for IEEE 1020 802.2 LLC. 1022 3. DF_CTL field (Word 3, bits 23-16 of FC-Header)must indicate 1023 the presence of a Network Header (0010 0000) on the First 1024 logical Frame of FC-4 sequences. 1026 8.2 R_CTL (FC-Header Word 0, bits 31-24) 1027 +--------------------------------------------------------------------+ 1028 | Feature | Support | Notes | 1029 +--------------------------------------------------------------------+ 1030 | Information Category (R_CTL Routing): | | | 1031 | FC-4 Device Data | Required | 1 | 1032 | Extended Link Data | Required | 2 | 1033 | FC-4 Link Data | Prohibited | | 1034 | Video Data | Prohibited | | 1035 | Basic Link Data | Required | 3 | 1036 | Link Control | Required | 4 | 1037 | R_CTL information | | | 1038 | Uncategorized | Prohibited | | 1039 | Solicited Data | Prohibited | | 1040 | Unsolicited Control | Required | 2 | 1041 | Solicited Control | Required | 2 | 1042 | Unsolicited Data | Required | 1 | 1043 | Data Descriptor | Prohibited | | 1044 | Unsolicited Command | Prohibited | | 1045 | Command Status | Prohibited | | 1046 +--------------------------------------------------------------------+ 1047 Notes: 1048 1. This is required for FC-4 (IP and ARP) packets 1049 - Routing bits of R_CTL field must indicate Device Data 1050 frames (0000). 1051 - Information Category of R_CTL field must indicate 1052 Unsolicited Data (0100). 1053 2. This is required for Extended Link Services. 1055 3. This is required for Basic Link Services. 1057 4. This is required for Link Control frames. 1059 8.3 F_CTL (FC-Header Word 2, bits 23-0) 1060 +--------------------------------------------------------------------+ 1061 | Feature | Support | Notes | 1062 +--------------------------------------------------------------------+ 1063 | Exchange Context | Settable | | 1064 | Sequence Context | Settable | | 1065 | First / Last / End Sequence (FS/LS/ES) | Settable | | 1066 | Chained Sequence | Prohibited | | 1067 | Sequence Initiative (SI) | Settable | 1 | 1068 | X_ID Reassigned / Invalidate | Prohibited | | 1069 | Unidirectional Transmit | Settable | | 1070 | Continue Sequence Condition | Required | 2 | 1071 | Abort Seq. Condition -continue and single seq.| Required | 3 | 1072 | Relative Offset - Unsolicited Data | Settable | 4 | 1073 | Fill Bytes | Settable | | 1074 +--------------------------------------------------------------------+ 1075 Notes: 1076 1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for 1077 sending data to each N_Port in the network and a dedicated 1078 RX_ID for receiving data from each N_Port as well. Exchanges 1079 are used in a unidirectional mode, thus setting sequence 1080 initiative is not valid for FC-4 frames. Sequence initiative 1081 is valid when using Extended Link Services. 1083 2. This field is required to be 00, no information. 1085 3. Sequence error policy is requested by an exchange originator 1086 in the F_CTL Abort Sequence Condition bits in the first data 1087 frame of the exchange. For classes 1 and 2, ACK frame is 1088 required to be "continuous sequence". 1090 4. Relative offset prohibited on all other types (Information 1091 Category) of frames. 1093 8.4 Sequences 1094 +---------------------------------------------------------------------+ 1095 | Feature | Support |Notes | 1096 +---------------------------------------------------------------------+ 1097 | Class 2 open sequences / exchange | 1 | 1 | 1098 | Length of seq. not limited by end-to-end credit | Required | 2 | 1099 | Maximum sequence size - IP sequences | 65536 | 3 | 1100 | Maximum sequence size - ARP sequences | 532 | 4 | 1101 | Capability to receive sequence of maximum size | Allowed | 5 | 1102 | Sequence Streaming | Prohibited | 6 | 1103 | Stop Sequence Protocol | Prohibited | | 1104 | ACK_0 support | Allowed | 7 | 1105 | ACK_1 support | Required | 7 | 1106 | ACK_N support | Prohibited | | 1107 | Class of Service for transmitted sequences | 1, 2 or 3 | 8 | 1108 | Continuously Increasing Sequence Count | Allowed | 9,10 | 1109 +---------------------------------------------------------------------+ 1110 Notes: 1111 1. Only one active sequence per exchange is allowed. 1113 2. A sequence initiator shall be capable of transmitting 1114 sequences containing more frames than the available credit 1115 indicated by a sequence recipient at login. FC-PH [2] end-to 1116 end flow control rules will be followed when transmitting such 1117 sequences. 1119 3. Maximum sequence size is 65535 bytes. Thus if the maximum IP 1120 packet size (MTU) is limited to 65280 bytes, then after 1121 accounting for 8 bytes of LLC/SNAP, we stll have 1122 (65535 - 65280 -8 = 247 bytes) for header overhead. 1124 4. Maximum size ARP packet is 532 bytes (including LLC/SNAP 1125 headers). 1127 5. Some OS environments may not handle the max MTU of 65535. It 1128 is up to the administrator to configure the Max MTU for all 1129 systems. 1131 6. All class 3 sequences are assumed to be non-streamed. 1133 7. Only applies for Class 1 and 2. Use of ACK_1 is default, 1134 ACK_0 used if indicated by sequence recipient at login. 1136 8. The administrator configured class of service is used, except 1137 where otherwise specified (e.g. Broadcasts are always sent in 1138 class 3). 1140 9. Review Appendix B, "Reliability in Class 3". 1142 10. The first frame of the first sequence of anew exchange must 1143 have SEQ_CNT = 0 [2]. 1145 8.5 Exchanges 1146 +--------------------------------------------------------------------+ 1147 | Feature | Support | Notes | 1148 +--------------------------------------------------------------------+ 1149 | X_ID interlock support | Allowed | 1 | 1150 | OX_ID=FFFF | Prohibited | | 1151 | RX_ID=FFFF | Allowed | 2 | 1152 | Action if no exchange resources available | P_RJT | 3 | 1153 | Long Lived Exchanges | Allowed | 4 | 1154 | Reallocation of Idle Exchanges | Allowed | | 1155 +--------------------------------------------------------------------+ 1156 Notes: 1157 1. Only applies to Classes 1 and 2, supported by the exchange 1158 originator. A Port shall be capable of interoperating with 1159 another Port that requires X_ID interlock. The exchange 1160 originator facility within the Port shall use the X_ID 1161 Interlock protocol in such cases. 1163 2. An exchange responder is not required to assign RX_IDs. If a 1164 RX_ID of FFFF is assigned, it is identifying exchanges based 1165 on S_ID / D_ID / OX_ID only. 1167 3. In Classes 1 and 2, a Port shall reject a frame that would 1168 create a new exchange with a P_RJT containing reason code 1169 "Unable to establish exchange". In Class 3, the frame would be 1170 dropped. 1172 4. When an exchange is created between 2 Ports for IP/ARP data, 1173 it remains active while the ports are logged in with each 1174 other. An exchange shall not transfer Sequence Initiative 1175 (SI). Broadcasts and ELS commands may use short lived 1176 exchanges. 1178 8.6 ARP 1179 +--------------------------------------------------------------------+ 1180 | Feature | Support | Notes | 1181 +--------------------------------------------------------------------+ 1182 | ARP Server Support | Prohibited | 1 | 1183 | Response to ARP requests | Required | 2 | 1184 | ARP requests transmitted as broadcast message | Required | | 1185 | Class of Service for ARP requests | 3 | 3 | 1186 | Class of Service for ARP replies | 1, 2 or 3 | 4 | 1187 +--------------------------------------------------------------------+ 1188 Notes: 1189 1. Well-known Address FFFFFC is not used for ARP requests. Frames 1190 from Well-known Address FFFFFC are not considered to be ARP 1191 frames. Broadcast support is required for ARP. 1193 2. The IP Address is mapped to a specific MAC address with ARP. 1195 3. An ARP request is a broadcast message, thus Class 3 is always 1196 used. 1198 4. An ARP reply is a normal sequence, thus the administrator 1199 configured class of service is used. 1201 8.7 Extended Link Services (ELS) 1202 +--------------------------------------------------------------------+ 1203 | Feature | Support | Notes | 1204 +--------------------------------------------------------------------+ 1205 | Class of service for ELS commands / responses | 1,2 or 3 | 1 | 1206 | Explicit N-Port Login | Required | | 1207 | Explicit F-Port Login | Required | | 1208 | FLOGI ELS command | Required | | 1209 | PLOGI ELS command | Required | | 1210 | ADISC ELS command | Required | | 1211 | PDISC ELS command | Allowed | 2 | 1212 | FAN ELS command | Required | 5 | 1213 | LOGO ELS command | Required | | 1214 | FARP-REQ ELS command | Allowed | 3 | 1215 | FARP-RES ELS command | Required | 3 | 1216 | Other ELS command support | Allowed | 4 | 1217 +-----------------------------------------------+------------+-------+ 1218 Notes: 1219 1. The administrator configured class of service is used. 1221 2. PDISC is prohibited as requester. ADISC should be used 1222 instead. As a responder, an implementation may need to respond 1223 to both ADISC and PDISC for compatibility with other 1224 specifications. 1226 3. FARP is allowed as Requester but required as Responder 1228 4. If other ELS commands are received an LS_RJT may be sent. NOP 1229 is not required by this specification, and should not be used 1230 as a mechanism to terminate exchanges. 1232 5. Required for FL_Ports 1234 8.8 Login Parameters 1236 Unless explicitly noted here, a compliant implementation shall use 1237 the login parameters as described in [4]. 1239 8.8.1 Common Service Parameters - FLOGI 1241 - FC-PH Version, lowest version may be 0x09 to indicate 1242 'minimum 4.3'. 1244 - Can't use BB_Credit=0 for N_Port on a switched Fabric 1245 (F_Port). 1247 8.8.2 Common Service Parameters - PLOGI 1249 - FC-PH Version, lowest version may be 0x09 to indicate 1250 'minimum 4.3'. 1251 - Can't use BB_Credit=0 for N_Port in a Point-to-Point 1252 configuration 1254 - Random Relative Offset is allowed. 1256 - Note that the 'Receive Data Field Size' fields specified in 1257 the PLOGI represent both optional headers and payload. 1259 - The MAC Address can therefore be extracted from the 6 lower 1260 bytes of the WW_PN field (when the IEEE 48-bit Identifier 1261 format is chosen as the NAA) during PLOGI or ACC payload 1262 exchanged during Fibre Channel Login [2]. 1264 - The MAC Address can also be extracted from the WW_PN field in 1265 the Network Header during ADISC (and ADISC ACC), or PDISC 1266 (and PDISC ACC). 1268 8.8.3 Class Service Parameters - PLOGI 1270 - Discard error policy only. 1272 ACKNOWLEDGEMENT 1274 This specification is based on FCA IP Profile, Version 3.3. The FCA 1275 IP Profile was a joint work of the Fibre Channel Association (FCA) 1276 vendor community. The following companies and organizations have 1277 contributed to the creation of the FCA IP Profile: Adaptec, Ancor, 1278 Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar, 1279 Gadzoox, Hewlett Packard, Interphase, Jaycor, LLNL, McData, Migration 1280 Associates, Orca Ssytems, Prisa, Q-Logic, Symbios, Systran, 1281 Tektronix, Univ. of Minnesota, Univ. of New Hamshire. 1283 REFERENCES 1285 [1] FCA IP Profile, Revision 3.3, May 15, 1997 1287 [2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI 1288 X3.230-1994 1290 [3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1291 1996 1293 [4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.4, October 1294 21, 1996 1296 [5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), 1297 Rev.1.7, October 7, 1996 1299 [6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), 1300 Rev. 7.4, ANSI X3.297-1996 1302 [7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996 1304 [8] Postel, J. and Reynolds, J., "A standard for the Transmission of 1305 IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, Feb, 1988 1307 [9] Plummer, D. "An Ethernet Address Resolution Protocol -or- 1308 Converting Network Addresses to 48-bit Ethernet Address for 1309 Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, Nov 1310 1982. 1312 [10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995 1314 [11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), 1315 Rev. 9.1, ANSI X3.xxx-199x 1317 [12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", 1318 Ancot Corporation 1320 [13] Fibre Channel -Gigabit Communications and I/O for Computers 1321 Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2 1323 [14] [ns008.pdf on ftp.network.com] 1324 AUTHORS' ADDRESSES 1325 Murali Rajagopal 1326 Gadzoox Networks, Inc. 1327 711 Kimberly Avenue, Suite 100 1328 Placentia, CA 92870 1330 Phone: +1 714 577 6805 1331 Fax: +1 714 524 8508 1332 Email: murali@gadzoox.com 1334 Raj Bhagwat 1335 Gadzoox Networks, Inc. 1336 711 Kimberly Avenue, Suite 100 1337 Placentia, CA 92870 1339 Phone: +1 714 577 6806 1340 Fax: +1 714 524 8508 1341 Email: raj@gadzoox.com 1343 Wayne Rickard 1344 Gadzoox Networks, Inc. 1345 711 Kimberly Avenue, Suite 100 1346 Placentia, CA 92870 1348 Phone: +1 714 577 6803 1349 Fax: +1 714 524 8508 1350 Email: wayne@gadzoox.com 1352 APPENDIX - A 1353 FIBRE CHANNEL OVERVIEW 1355 A.1 Brief Tutorial 1357 FC standard [2] defines 4 "levels" (not layers) for its protocol 1358 description: FC-0, FC-1, FC-2, FC-3, and FC-4. The first three levels 1359 (FC-0, FC-1, FC-2) are largely concerned with the physical formatting 1360 and control aspects of the protocol. FC-3 is architecturally defined 1361 but not unspecified at this time. FC-4 is meant for supporting profiles 1362 of higher protocols such as IP and Small Computer System Interface (SCSI) 1363 and supports a relatively small set of higher level protocols compared to 1364 LAN protocols such as IEEE 802.3. 1366 FC devices are called "Nodes", each of which has at least one "Port" to 1367 connect to other ports. A Node may be a workstation, a disk drive or 1368 disk array, a camera, a display unit, etc. The set of hardware components, 1369 and transceivers, connecting two or more node ports is called a topology. 1371 A "Link" is two unidirectional paths flowing in opposite directions and 1372 connecting two Ports within adjacent Nodes. 1374 FC Nodes communicate using higher layer protocols such as SCSI and IP 1375 and are configured to operate using one of the following 1376 networking topologies: 1377 - Point-to-Point 1378 - Private Loop 1379 - Public Loop (attachment to a Fabric) 1380 - Fabric 1381 The point-to-point is the simplest of the four topologies, where only 1382 two nodes communicate with each other. The private loop may connect a 1383 number of devices (max 126) in a logical ring much like Token Ring and 1384 is distinguished from a public loop by the absence of a Fabric Node 1385 participating in the loop. The Fabric topology is a switched network 1386 where any attached node can communicate with any other. 1388 Table below summarizes the usage of port types depending on its location 1389 [12]. Note that E-Port is not relevant to any discussion in this 1390 specification but is included below for completeness. 1392 +-----------+-------------+-----------------------------------------+ 1393 | Port Type | Location | Topology Associated with | 1394 +-----------+-------------+-----------------------------------------+ 1395 | N_Port | Node | Point-to-Point or Fabric | 1396 +-----------+-------------+-----------------------------------------+ 1397 | NL_Port | Node |In N_Port mode -Point-to-Point or Fabric | 1398 | | |In NL_Port mode - Arbitrated Loop | 1399 +-----------+-------------+-----------------------------------------+ 1400 | F_Port | Fabric | Fabric | 1401 +-----------+-------------+-----------------------------------------+ 1402 | FL_Port | Fabric | In F_Port mode - Fabric | 1403 | | | In FL_Port mode - Arbitrated Loop | 1404 +-----------+-------------+-----------------------------------------+ 1405 | E_Port | Fabric | Internal Fabric Expansion | 1406 +-----------+-------------+-----------------------------------------+ 1407 A.2 Fibre Channel Header Fields 1409 Fibre Channel Frame Header, Network Header, and payload carrying IP Packet 1411 +---+----------------+----------------+----------------+--------------+ 1412 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1413 +---+----------------+----------------+----------------+--------------+ 1414 |0 | R_CTL | D_ID | 1415 +---+----------------+----------------+----------------+--------------+ 1416 |1 | CS_CTL | S_ID | 1417 +---+----------------+----------------+----------------+--------------+ 1418 |2 | TYPE | F_CTL | 1419 +---+----------------+----------------+----------------+--------------+ 1420 |3 | SEQ_ID | DF_CTL | SEQ_CNT | 1421 +---+----------------+----------------+----------------+--------------+ 1422 |4 | OX_ID | RX_ID | 1423 +---+--------+-------+----------------+----------------+--------------+ 1424 |5 | Parameter (Control or Relative Offset for Data ) | 1425 +---+-----------------------------------------------------------------+ 1426 |6 | NAA | Network_Dest_Address (Hi order bits) | 1427 +---+--------+-------+----------------+----------------+--------------+ 1428 |7 | Network_Dest_Address (Lo order bits) | 1429 +---+--------+-------+----------------+----------------+--------------+ 1430 |8 | NAA | Network_Src_Address (Hi order bits) | 1431 +---+--------+-------+----------------+----------------+--------------+ 1432 |9 | Network_Src_Address (Lo order bits) | 1433 +---+----------------+----------------+----------------+--------------+ 1434 |10 | DSAP | SSAP | CTRL | OUI | 1435 +---+----------------+----------------+----------------+--------------+ 1436 |11 | OUI | PID | 1437 +---+----------------+----------------+----------------+--------------+ 1438 |12 | IP Packet Data | 1439 +---+----------------+----------------+----------------+--------------+ 1440 |13 | ... | 1441 +---+----------------+----------------+----------------+--------------+ 1443 The FC header as shown in the above diagrams contains routing and other 1444 control information to manage frames, sequences, and exchanges. The 1445 frame header is sent as 6 transmission words immediately following an SOF 1446 delimiter and before the data field. 1448 D_ID and S_ID: 1450 FC uses destination address routing [12], [13]. Frame routing in 1451 a point-to-point topology is trivial. 1453 For the Arbitrated Loop topology, with the destination NL_Port on 1454 the same AL, the source port must pick the destination port, 1455 determine its AL Physical Address, and "Open" the destination 1456 port. The frames must pass through other NL_Ports or the FL_Port 1457 on the loop between the source and destination, but these ports 1458 do not capture the frames. They simply repeat and transmit the 1459 frame. Either communicating port may "Close" the circuit. 1461 When the destination port is not on the same AL, the source 1463 NL_Port must open the FL_Port attached to a Fabric. Once in the 1464 Fabric, the Fabric routes the frames again to the destination. 1466 In a Fabric topology, the Fabric looks into the frame header, 1467 extracts the destination address (D_ID), searches its own routing 1468 tables, and sends the frame to the destination port along the path 1469 chosen. The process of choosing a path may be performed at each 1470 fabric until the F_Port attached to the destination N_Port is 1471 reached. 1473 R_CTL (Routing Control) and TYPE(data structure): 1475 Frames for each FC-4 can be easily distinguished from the others 1476 at the receiving port using the R_CTL (Routing Control) and TYPE 1477 (data structure) fields in the frame header. 1479 The R_CTL has two sub-fields: Routing bits and Information category. 1480 The Routing bits sub-field has specific values that mean FC-4 data 1481 follows and the Information Category tells the receiver the "Type" 1482 of data contained in the frame. The R_CTL and TYPE code points are 1483 shown in the diagrams. 1485 Other Header fields: 1487 F_CTL (Frame Control) and SEQ_ID (Sequence Identification), 1488 SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), 1489 RX_ID (Responder exchange Identifier), and Parameter fields are 1490 used to manage the contents of a frame, and mark information 1491 exchange boundaries for the destination port. 1493 F_CTL(Frame Control): 1495 The FC_CTL field is a 3-byte field that contains information 1496 relating to the frame content. Most of the other frame header 1497 fields are used for frame identification. Among other things, 1498 bits in this field indicate the first sequence, last sequence, or 1499 end sequence. Sequence Initiative bit is used to pass control of 1500 the next sequence in the exchange to the recipient. 1502 SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count): 1504 This is used to uniquely identify sequences within an Exchange. 1505 The uniquely identifies any active sequence. 1506 SEQ_CNT is used to uniquely identify frames within a Sequence to 1507 assure sequentiality of frame reception, and to allow unique 1508 correlation of link control frames with their related data frames. 1510 Originator Exchange Identifier (OX_ID) and Responder Exchange 1511 Identifier (RX_ID): 1513 The OX_ID value provides association of frames with specific 1514 Exchanges originating at a particular N_Port. The RX_ID field 1515 provides the same function that the OX_ID provides for the 1516 Exchange Originator. The OX_ID is meaningful on the Exchange 1517 Originator, and the RX_ID is meaningful on the Responder. 1519 DF_CTL (Data Field Control): 1521 The DF_CTL field specifies the presence or absence of optional 1522 headers between the Frame header and Frame Payload 1524 PARAMETER: 1526 The Parameter field has two meanings, depending on Frame type. 1527 For Link Control Frames, the Parameter field indicates the 1528 specific type of link Link Control frame. For Data frames, this 1529 field contains the Relative Offset value. This specifies an 1530 offset from an Upper Layer Protocol buffer from a base address. 1532 Code Points for FC Frame with IP packet Data 1534 +---+----------------+----------------+----------------+--------------+ 1535 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1536 +---+----------------+----------------+----------------+--------------+ 1537 | 0 | 0x04 | D_ID | 1538 +---+----------------+----------------+----------------+--------------+ 1539 | 1 | 0x00 | S_ID | 1540 +---+----------------+----------------+----------------+--------------+ 1541 | 2 | 0x05 | F_CTL | 1542 +---+----------------+----------------+----------------+--------------+ 1543 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 1544 +---+----------------+----------------+----------------+--------------+ 1545 | 4 | OX_ID | RX_ID | 1546 +---+----------------+----------------+----------------+--------------+ 1547 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 1548 +---+------+----------------------------------------------------------+ 1549 | 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) | 1550 +---+------+---------+----------------+----------------+--------------+ 1551 | 7 | Dest. MAC (Lo order bits) | 1552 +---+------+----------+----------------+------------------------------+ 1553 | 8 | 0001 | 0x000 | Src. MAC (Hi order bits) | 1554 +---+------+---------+----------------+----------------+--------------+ 1555 | 9 | Src. MAC (Lo order bits) | 1556 +---+----------------+----------------+----------------+--------------+ 1557 |10 | 0xAA | 0xAA | 0x03 | 0x00 | 1558 +---+----------------+----------------+----------------+--------------+ 1559 |11 | 0x00-00 | 0x08-00 | 1560 +---+----------------+----------------+----------------+--------------+ 1561 |12 | IP Packet Data | 1562 +---+----------------+----------------+----------------+--------------+ 1563 |13| ... | 1564 +---+----------------+----------------+----------------+--------------+ 1566 The Code Points for FC Frames with ARP packets are very similar to IP 1567 packets with the exception of PID value in Word 11 which is set to 1568 0x08-06. Also, the Network Header as shown above appears only in the 1569 first logical FC Sequence carrying IP. In the case, where FC frames 1570 carry ARP packets it is always present because these are single frame 1571 sequences. 1573 A.3 Acronyms and Glossary of FC Terms 1575 It is assumed that the reader is familiar with the terms and acronyms 1576 used in the FC protocol specification [2]. The following is provided for 1577 easy reference. 1579 A.3.1 Acronyms 1581 First Frame: The frame that contains the SOFi field. This means a logical 1582 first and may not necessarily be the first frame temporally received in a 1583 sequence. 1585 Code Point: The coded bit pattern associated with control fields in frames 1586 or packets. 1588 PDU: Protocol Data Unit 1590 ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for 1591 aborting an exchange based on the ABTS recipient setting the 1592 Last_Sequence bit in the BA_ACC ELS to the ABTS 1594 ADISC: Discover Address. An ELS for discovering the Hard Addresses (the 1595 24 bit NL_Port Identifier) of N_Ports 1597 D_ID: Destination ID 1599 ES: End sequence. This FCTL bit in the FC header indicates this frame is 1600 the last frame of the sequence. 1602 FAN: Fabric Address Notification. An ELS sent by the fabric to all known 1603 previously logged in ports following an initialization event. 1605 FLOGI: Fabric Login. 1607 LIP: Loop Initialization. A primitive sequence used by a port to detect 1608 if it is part of a loop or to recover from certain loop errors. 1610 Link: Two unidirectional paths flowing in opposite directions and 1611 connecting two Ports within adjacent Nodes. 1613 LOGO: Logout. 1615 LR: Link reset. A primitive sequence transmitted by a port to initiate 1616 the link reset protocol or to recover from a link timeout. 1618 LS: Last sequence of Exchange. This FCTL bit in the FC header indicates 1619 the sequence is the last sequence of the exchange. 1621 Network Address Authority: A 4-bit field specified in Network Headers 1622 that distinguishes between various name registration authorities that 1623 may be used to identify the WW_PN and the WW_NN. NAA=b'0001' indicates 1624 IEEE-48-bit MAC addresses 1626 Node: A collection of one or more Ports identified by a unique World 1627 Wide Node Name (WW Node Name). 1629 NOS: Not Operational. A primitive sequence transmitted to indicate that 1630 the port transmitting this sequence has detected a link failure or is 1631 offline, waiting for OLS to be received. 1633 OLS: Off line. A primitive sequence transmitted to indicate that the 1634 port transmitting this sequence is either initiating the link 1635 initialization protocol, receiving and recognizing NOS, or entering the 1636 offline state. 1638 PDISC: Discover Port. An ELS for exchanging Service Parameters without 1639 affecting login state. 1641 Primitive Sequence: A primitive sequence is an Ordered Set that is 1642 transmitted repeatedly and continuously. 1644 Private Loop Device: A device that does not attempt fabric login (FLOGI) 1645 and usually adheres to PLDA. The Area and Domain components of the 1646 NL_Port ID must be 0x0000. These devices cannot communicate with any 1647 port not in the local loop. 1649 Public Loop Device: A device whose Area and Domain components of the 1650 NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the 1651 device must attempt to open AL_PA 0x00 and attempt FLOGI. These devices 1652 communicate with devices on the local loop as well as devices on the 1653 other side of a Fabric. 1655 Port: The transmitter, receiver and associated logic at either end of a 1656 link within a Node. There may be multiple Ports per Node. Each Port is 1657 identified by a unique Port_ID, which is volatile, and a unique World 1658 Wide Port Name (WW Port Name), which is unchangeable. In this document, 1659 the term "port" may be used interchangeably with NL_Port or N_Port. 1661 Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. In 1662 a Fibre Channel frame header, the Port_ID is referred to as S_ID (Source 1663 ID) to identify the port originating a frame, and D_ID to identify the 1664 destination port. The Port_ID of a given port is volatile (changeable). 1665 The mechanisms through which a Port_ID may change in a Fibre Channel 1666 topology are outside the scope of this document. 1668 PLOGI: Port Login. 1670 SI: Sequence Initiative 1672 World Wide Port_Name (WW_PN): Fibre Channel requires each Port to have 1673 an unchangeable WW_PN. Fibre Channel specifies a Network Address 1674 Authority (NAA) to distinguish between the various name registration 1675 authorities that may be used to identify the WW_PN. A 4-bit NAA 1676 identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address 1677 together make this a 64-bit field. 1679 World Wide Node_Name (WW_NN): Fibre Channel identifies each Node with a 1680 unchangeable WW_NN. In a single port Node, the WW_bNN and the WW_PN may be 1681 identical. 1683 APPENDIX - B 1685 B.1 RELIABILITY IN CLASS 3 1687 Problem: 1688 Sequence ID reuse in Class 3 can conceivably result in missing frame 1689 aliasing with no corresponding detection at the FC2 level. 1691 Prevention: 1692 This specification requires one of the following methods if Class 3 is 1693 used. 1695 - Continuously increasing Sequence Count (new Login Bit) - both 1696 sides must set When an N_Port sets the PLOGI login bit for 1697 continuously increasing SEQ_CNT, it is guaranteeing that it 1698 will transmit all frames within an exchange using a continuously 1699 increasing SEQ_CNT (see description below). 1701 - After using all SEQ_IDs (0-255) once, must start a new Exchange. 1702 It is recommended that a minimum of 4 Exchanges be used before 1703 an OX_ID can be reused. 1705 - Note: If an implementation is not checking the OX_ID when 1706 reassembling sequences, the problem can still occur. Cycling 1707 through some number of SEQ_IDs, then jumping to a new exchange 1708 does not solve the problem. SEQ_IDs must still be unique between 1709 two N_Ports, even across exchanges. 1711 - Use only single-frame Sequences. 1713 B.2 CONTINUOUSLY INCREASING SEQ_CNT 1715 This method allows the recipient to check incoming frames, knowing 1716 exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not 1717 repeat for 65,536 frames, the aliasing problem is significantly reduced. 1719 A login bit (PLOGI) is used to indicate that a device always uses a 1720 continuously increasing SEQ_CNT, even across transfers of sequence 1721 initiative. This bit is necessary for interoperability with some 1722 devices, and it provides other benefits as well. 1724 In the FC-PH-3 [11], the following is supported: 1726 Word 1, bit 17 - SEQ_CNT (S) 1727 0 = Normal FC-PH rules apply 1728 1 = Continuously Increasing SEQ_CNT 1730 Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will 1731 transmit all frames within an exchange using a continuously increasing 1732 SEQ_CNT. Each exchange shall start with SEQ_CNT = 0 in the first frame, 1733 and every frame transmitted after that shall increment the previous 1734 SEQ_CNT by one, even across transfers of sequence initiative. Any frames 1735 received from the other N_Port in the exchange shall have no effect on 1736 the transmitted SEQ_CNT. 1738 APPENDIX - C 1740 Other Mechansims for FC Layer Mappings 1742 Each method should have some mechanism to ensure PLOGI has completed 1743 successfully before data is sent. A related concern in large networks is 1744 limiting concurrent logins to only those ports with active IP traffic. 1746 C.1 Login on Cached Mapping Information 1748 This method insulates the level performing LOGIN from the level 1749 interpreting ARP. It is more accommodating of non-ARP mechanisms for 1750 building the FC-layer mapping table. 1752 1. Broadcast messages that carry a Network Header contain 1753 the S_ID on the FC-header and WW_PN in the Network-header. 1754 Caching this information provides a correlation of Port_ID to 1755 WW_PN. If the received Broadcast message is compliant with this 1756 specification, the WW_PN will be the MAC Address. 1758 2. The WW_PN is "available" if Login has been performed to the 1759 Port_ID and flagged. If login has not been performed, the 1760 WW_PN is "unavailable". 1762 3. If an outbound packet is destined for a port that is 1763 "unavailable", the cached information (from broadcast) is used 1764 to look up the Port_ID. 1766 4. After sending an ELS PLOGI command (Port Login) to the Port (from 1767 a higher level entity at the host), waiting for an outbound packet 1768 before sending this Port Login conserves resources for only for 1769 those ports which wish to establish communication. 1771 5. After Port Login completes (ACC received), the outbound packet 1772 can be forwarded. At this point in time, both ends have the 1773 necessary information to complete their association. 1776 C.2 Login on ARP Parsing 1778 This method performs LOGIN sooner by parsing ARP before passing it up to 1779 higher levels for IP/MAC Address correlation. It requires a low-level 1780 awareness of the IP address, and is therefore protocol-specific. 1782 1. When an ARP Broadcast Message is received, the S_ID is extracted 1783 from the FC header and the corresponding Network_Source_Address 1784 from the Network Header. 1786 2. The ARP payload is parsed to determine if (a) this host is the 1787 target of the ARP request (Target IP Address match), and (b) if 1788 this host is currently logged in with the port (Port_ID = S_ID) 1789 originating the ARP broadcast. 1791 3. The ARP is passed to higher level for ARP Response generation. 1793 4. If a Port Login is required, an ELS PLOGI command (Port Login) 1794 is sent immediately to the Port originating the ARP Broadcast. 1796 5. After Port Login completes, an ARP response can be forwarded. 1797 Note that there are two possible scenarios: 1799 - The ACC to PLOGI returns before the ARP reply is processed 1800 and the ARP Reply is immediately forwarded. 1802 - The ARP reply is delayed, waiting for ACC (successful 1803 Login). 1805 6. At this point in time, both ends have the necessary 1806 information to complete their 1807 association. 1809 C.3 Login to Everyone 1811 In Fibre Channel topologies with a limited number of ports, it may be 1812 efficient to unconditionally login to each port. This method is 1813 discouraged in fabric and public loop environments. 1815 After Port Login completes, the MAC Address to Port_ID Address tables 1816 can be constructed. 1818 C.4 Static Table 1820 In some loop environments with a limited number of ports, a static 1821 mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be maintained. 1822 The FC layer will always know the destination Port_ID based on the 1823 table. The table is typically downloaded into the driver at 1824 configuration time. This method scales poorly, and is therefore not 1825 recommended. 1827 [draft-ietf-ipfc-fibre-channel-01.txt] 1828 [This INTERNET DRAFT expires on Mar 18, 1999]