idnits 2.17.1 draft-ietf-ipfc-fibre-channel-00.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-24) 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 33 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 33 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 208 instances of too long lines in the document, the longest one being 18 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... and its wo...' == Line 19 has weird spacing: '...aterial or to...' == Line 52 has weird spacing: '... most of th...' == Line 66 has weird spacing: '...promote inter...' == Line 69 has weird spacing: '...packets over ...' == (7 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' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 13 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 Dec 22, 1998) (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-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 Fibre Channel (FC) is a high speed serial interface technology that 31 supports several higher layer protocols including Small Computer 32 System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI 33 has been the only widely used protocol over Fibre Channel. Existing 34 Fibre Channel standards [3] do not adequately specify how IP packets 35 may be transported over Fibre Channel and how IP addresses are 36 resolved to FC addresses. The purpose of this document is to specify 37 a way of encapsulating IP and Address Resolution Protocol(ARP) over 38 Fibre Channel and also to describe a mechanism for IP address 39 resolution. 41 1. Introduction 43 Fibre Channel is a gigabit speed networking technology primarily used 44 for Storage Area Networking (SAN). FC is standardized under American 45 National Standards Institute (ANSI)and has specified a number of 46 documents describing its protocols, operations, and services. 48 Need: 50 Currently, Fibre Channel is predominantly used for communication 51 between storage devices and servers using the SCSI protocol, with 52 most of the servers still communicating with each other over LANs. 53 Although, the Fibre Channel standard [3] has architecturally defined 54 support for IP encapsulation and address resolution, it is 55 inadequately specified. ([3] prohibits broadcasts thus loops are not 56 covered; [10] has no support for Class 3) 58 This has lead to a nonstandard way of using IP over FC in the past. 59 Once, such a standard method is completely specified, servers can 60 directly communicate with each other using IP over FC, possibly 61 boosting performance in Server host-to-host communications. This 62 technique will be especially useful in a Clustering Application. 64 Objective: 66 The major objective of this specification is to promote inter- 67 operable implementations of IP over Fibre Channel. This 68 specification describes a method for encapsulating IPv4 and Address 69 Resolution protocol (ARP) packets over Fibre Channel. This 70 specification accommodates any FC topology (loop, fabric, or point- 71 to-point) and any FC class of service (1, 2 or 3). Use of IEEE 802.2 72 LLC/SNAP encapsulation for IP and ARP as specified in this document 73 shall not preclude the use of same encapsulation technique for other 74 protocol stacks (e.g. IPX, AppleTalk). 76 Organization: 78 Section 2 states the problem that is solved in this specification. 79 Section 3 describes the techniques used for encapsulating IP and ARP 80 packets in a FC sequence. 82 Section 4 discusses ARP (IP address to MAC address) and the required 83 mappings and operation. Section 5 discusses the FC Layer mappings 84 (MAC address to Port_ID). Section 6 provides a discussion on 85 validation of the FC-layer mapping for the different FC topologies. 86 Section 7 describes the "Exchange" Management in FC. Section 8 is a 87 summary section and provides a quick summary of the FC header 88 settings, FC Link Service Commands, and a summarized reference to 89 features supported in ARP, FC Sequences, FC Exchanges, and FC Login 90 Parameters. 92 Appendix A provides a brief overview of the FC Protocols and Networks 93 along with a list of acronyms and a glossary of FC Terms used in this 94 specification. Appendix B addresses reliability in Class 3. 96 2. Problem Statement 98 This draft addresses two problems: 99 - A sequence format definition and encapsulation mechanism for IP 100 and ARP packets over FC 101 - An Address Resolution mechanism. 103 As noted earlier, the existing FC Standards [3], [10] are inadequate. 104 A solution to both problems has been proposed by the Fibre Channel 105 Association (FCA)[1]. FCA is a industry consortium of Fibre Channel 106 vendor companies and not a standards body. This draft specification 107 is largely based on the proposed solution in [1] and is an attempt to 108 provide a standardized specification addressing both the above stated 109 problems. 111 3. IP/ARP Encapsulation 113 3.1 FC Frame Format 115 All FC frames have a standard format much like LAN 802.x protocols. 116 (See Appendix A for Fibre Channel related Acronyms and Glossary of 117 Terms.) However, the exact size of each frame varies depending on the 118 sizes of the variable fields. The FC frame structure is shown in 119 Fig. 1. 121 +-------+--------+-----------+----//-------+-----+-----+ 122 | SOF |Frame |Optional | Payload |CRC | EOF | 123 | (4B) |Header |Header | |(4B) |(4B) | 124 | | |<----------------------->| | | 125 | |(24B) | (0-2112B) | | | 126 +-------+--------+-----------+----//-------+-----+-----+ 128 Fig. 1 FC Frame Format 130 The Start of Frame (SOF) and End of Frame (EOF) are both 4 bytes long 131 and act as frame delimiters. 133 The CRC is 4 bytes long and uses the same 32-bit polynomial used in 134 FDDI and is specified in ANSI X3.139 Fiber Distributed Data 135 Interface. 137 The Frame Header is 24 bytes long and has several fields associated 138 with identification and control of the payload. The values and 139 options for the fields that are relevant to the IP and ARP payloads 140 will be discussed later. 142 A FC Optional Header allows up to 4 optional header fields: 144 - An Expiration Security Header (16 bytes) 145 - Network (16 bytes) 146 - Association (32 bytes) 147 - Device (up to 64 bytes). 149 The IP and ARP FC sequences are required to carry the Network_Header 150 optional header field which is 16 bytes long. Other types of optional 151 headers are prohibited. The use of the Network_Header for the IP and 152 ARP payload encapsulation is described below. 154 In FC an application level payload is called a Sequence. Typically, a 155 Sequence consists of more than one frame. Larger user data is 156 segmented and reassembled using two methods: Sequence Count and 157 Relative Offset. Use of Sequence Count is straight forward and data 158 blocks are sent using frames with increasing sequence counts (modulo 159 16). With Relative Offset, frames could temporally arrive out of 160 order. 162 When IP and ARP form the FC payload then only the First Frame of the 163 logical Sequence shall include the FC Network_Header. Care should 164 exercised when this is the case. Fig. 2 shows the logical First Frame 165 and logical subsequent frames rather than temporal ordering. 167 First Frame of a Logical FC Sequence 168 ---+------------+---------------------------+----------//----------+--- 169 | FC Header | FC Network Header | FC Sequence Data | 170 ---+------------+---------------------------+---------//-----------+--- 172 Subsequent Frames of a Logical FC Sequence 173 --+-----------+----------//------+-- 174 | FC Header | FC Sequence Data | 175 --+-----------+----------//------+-- 177 Fig. 2 FC Network Header in a Frame Sequence 179 The SOF, CRC, EOF control fields and other optional headers have been 180 omitted in the figure for clarity. 182 3.2 MTU 184 The Maximum Transmission Unit (MTU) for IP is defined as the length 185 of the IP packet, including IP headers. The theoretical maximum size 186 of an IP Packet is 65,535 bytes. In FC-4 the transmission unit is 187 "Information Unit" and not frames. An N_Port may transmit an 188 Information Unit using multiple frames. The receiving N_Port will 189 assemble the frames to reconstruct the sent Information Unit. The 190 size of a single Information Unit is limited to 2^32-1, which is very 191 large. However, restricting the IP over FC MTU helps in buffer 192 resource allocation at N_Ports. A MTU of 65,280 bytes allows for up 193 to 256 bytes of overhead. The IEEE 802.2 LLC/SNAP headers requires 8 194 bytes, leaving the rest 248 bytes for future uses. 196 There shall be a one-to-one mapping between an IP packet and a FC 197 sequence. In other words, one IP packet shall always map to only one 198 FC Sequence. 200 Note that, although the FC physical frame MTU is limited to 2112 201 bytes, it is hidden from IP and does not affect the IP MTU at FC-4. 203 3.3 FC Port and Node Network Addresses 205 FC devices are identified by Nodes and Ports. A Node is a collection 206 of one or more Ports identified by a unique nonvolatile 207 (unchangeable) 64-bit World Wide Node name (WWN_N). Each Port in a 208 node, is identified with a unique nonvolatile 64-bit World Wide Port 209 name (WWP_N), and a volatile (changeable) Port_ID. 211 Port_ID are 24-bits. In a FC frame header, the Port_ID is referred to 212 as S_ID (Source ID) to identify the port originating a frame, and 213 D_ID to identify the destination port. The Port_ID of a given port is 214 volatile (changeable). (The mechanisms through which a Port_ID may 215 change in a FC topology are outside the scope of this document.) 217 FC specifies a Network Address Authority (NAA) to distinguish between 218 the various name registration authorities that may be used to 219 identify the WWP_N and the WWP_N. A 4-bit NAA identifier, 12-bit 220 field set to 0x000 and an IEEE 48-bit MAC address together make the 221 64-bit WWN_N or the WWP_N addresses [2]. In a single port Node, the 222 WWN_N and the WWP_N may be identical. 224 The WWN_P names of the source and destinations are carried in the FC 225 Network Header. The format of the FC Network Header is shown in Fig. 226 3 and defined in the FC standards [2]. The Network header is 227 normally optional in FC but mandatory in this specification. The 4 228 most significant bits in each address denotes the Network Address 229 Authority (NAA) type. In this specification, the source and 230 destination NAA binary pattern '0001' indicates the IEEE-48 bit MAC 231 address and is the only code point that is allowed. 233 The NAA field allows FC networks to be bridged with other FC networks 234 or traditional LANs. The Source (Destination) MAC address occupies 235 the lower 48 bits of the Network_Source_Address 236 (Network_Dest_Address), and the upper 12 bits are set to 0x000. 238 +--------+---------------------------------------+ 239 | D_NAA |Network_Dest_Address (High-order bits) | 240 |(4 bits)| (28 bits) | 241 +--------+---------------------------------------+ 242 | Network_Dest_Address (Low-order bits) | 243 | (32 bits) | 244 +--------+---------------------------------------+ 245 | S_NAA |Network_Source_Address(High-order bits)| 246 |(4 bits)| (28 bits) | 247 +--------+---------------------------------------+ 248 | Network_Source_Address (Low-order bit) | 249 | (32 bits) | 250 +--------+---------------------------------------+ 252 Fig. 3 Format of the Network Header Field 254 3.4 FC Payload Format 256 The payload of an FC sequence carrying an IP packet shall use the 257 format shown in Fig. 4. Fig. 5 shows the format when the payload is 258 an ARP packet. However, both formats use the 8-byte LLC/SNAP header. 260 +-----------------+-----//----------+-------------//------------+ 261 | LLC/SNAP Header | IP Header | IP Data | 262 | (8 bytes) | (20 bytes min.) | (65280 -IP Header) bytes | 263 +-----------------+-----//----------+-------------//------------+ 265 Fig. 4 Format of FC Sequence Payload carrying IP 267 +-----------------+-------------------+ 268 | LLC/SNAP Header | ARP Packet | 269 | (8 bytes) | (28 bytes) | 270 +-----------------+-------------------+ 272 Fig. 5 Format of FC Sequence Payload carrying ARP 274 As noted above, since FC frames belonging to the same Sequence can be 275 delivered out of order over a Fabric, the IP Header must appear in 276 the frame that has relative random offset of 0. 278 A Logical Link Control (LLC) field along with a Sub Network Access 279 Protocol (SNAP) field is a method used to identify routed and bridged 280 non-OSI protocol PDUs and is defined in IEEE 802.2 and applied to IP 281 in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless 282 mode), the LLC header is 3-bytes long and consists of a 1-byte 283 Destination Service Access Point (DSAP)field, a 1-byte Source Service 284 Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 285 6. 287 +----------+----------+----------+ 288 | DSAP | SSAP | CTRL | 289 | (1 byte) | (1 byte | (1 byte) | 290 +----------+----------+----------+ 292 Fig. 6 LLC Format 294 The LLC's DSAP and SSAP values of 0xAA indicate that a SNAP header 295 follows. The LLC's CTRL value equal to 0x03 specifies Unnumbered 296 Information Command PDU. The LLC header value shall 0xAA-AA-03. 298 The SNAP header is 5 bytes long and consists of a 3-byte 299 Organizationally Unique Identifier (OUI) field and a 2-byte Protocol 300 Identifier as shown in Fig. 7 302 +------+------+-------+------+------+ 303 | OUI | PID | 304 | ( 3 bytes) | (2 bytes) | 305 +------+------+-------+------+------+ 307 Fig. 7 SNAP Format 309 The SNAP OUI value 0x00-00-00 specifies that the PID is an EtherType 310 (i.e., routed non-OSI protocol). 312 The SNAP PID Type field specifies the EtherType value. In particular, 313 the value of 0x08-00 indicates IP and value of 0x08-06 indicates ARP. 314 The complete LLC/SNAP header is shown in Fig. 8. 316 +----------+----------+----------+-------+-------+-------+-------+------+ 317 | DSAP | SSAP | CTRL | OUI | PID | 318 | (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes | 319 +----------+----------+----------+-------+-------+-------+-------+------+ 321 Fig. 8 LLC/SNAP Header 323 3.5 ARP Packet Format 325 The format of the encapsulated ARP packet is based on [9] and is 326 shown in Fig. 9. 328 The 'HW Type' field shall be set to 0x00-06 indicating IEEE 802 329 networks. 331 The 'Protocol' field shall be set to 0x08-00 indicating IP protocol. 332 The 'HW Addr Length' field shall be set to 0x06 indicating 6 bytes of 333 HW address. 335 The 'Protocol Addr Length' field shall be set to 0x04 indicating 4 336 bytes of IP address. 338 The 'Operation' Code field shall be either 0x00-01 for Request or 339 0x00- 02 for Reply. 341 +-------------------------+ 342 | HW Type | 2 bytes 343 +-------------------------+ 344 | Protocol | 2 bytes 345 +-------------------------+ 346 | HW Addr Length | 1 byte 347 +-------------------------+ 348 | Protocol Addr Length | 1 byte 349 +-------------------------+ 350 | Op Code | 2 bytes 351 +-------------------------+ 352 | HW Addr of Sender | 6 bytes 353 +-------------------------+ 354 | Protocol Addr of Sender | 4 bytes 355 +-------------------------+ 356 | HW Addr of Target | 6 bytes 357 +-------------------------+ 358 | Protocol Addr of Target | 4 bytes 359 +-------------------------+ 361 Fig. 9 ARP Packet Format 363 The 'HW Addr of Sender' field shall be the 6 byte IEEE MAC address of 364 the sender. 366 The 'Protocol Addr of Sender' field shall be the 4 byte IP address of 367 the sender. 369 The 'HW Addr of Target' field shall be set to zero if the 'Operation 370 Code' field is set to 1. Otherwise, it shall be set to the 6 byte 371 IEEE MAC address of the original sender of the ARP request. 373 The 'Protocol Addr of Target' field shall be set to the 4 byte IP 374 address of the target. 376 The ARP packet is 28 bytes long in this particular application. The 377 difference between an ARP Request Packet and an ARP Reply Packet is 378 given below: 380 1. ARP Request packet: 'Operation' Code field = 0x00-01 and the 'HW 381 Addr of Target' is set to 0x00-00-00-00-00-00. 383 2. ARP Reply packet: 'Operation' Code field = 0x00-02 and the 'HW 384 Addr of Target' is appropriately set to the address extracted 385 from the ARP Request packet's Sender address 387 An ARP Request message is defined as a FC broadcast sequence carrying 388 the ARP Request packet. The exact mechanism used to broadcast a FC 389 sequence depends on the topology and will be discussed in the next 390 section. Compliant ARP broadcast messages shall include Network 391 Headers. 393 An ARP Reply message is defined as an ARP Reply packet encapsulated 394 in a FC sequence. 396 4. Address Resolution 398 4.1 Problem Description 400 Address Resolution is concerned with associating IP addresses with FC 401 Port addresses. As described earlier, FC device ports have two 402 addresses: 403 - a non-volatile unique 64-bit address called World Wide Port_Name 404 (WWP_N) 406 - a volatile 24-bit address called a Port_ID 408 The Address Resolution mechanism therefore will need two levels of 409 mapping: 411 1. A mapping from IP address to the WWP_N address(i.e., IEEE 412 48-bit MAC address) 414 2. A mapping from WWP_N to the Port_ID 416 The address resolution problem is compounded by the fact that the 417 Port_ID is volatile and the second mapping has to be validated before 418 use. Moreover, this validation process can be different depending on 419 the FC network topology used. 421 Architecturally, the first level of mapping and control operation is 422 handled by the ARP layer, and the second level of mapping and control 423 by the FC layer. 425 4.2 ARP Layer Mapping and Operation 427 Whenever a source FC port with a designated IP address wishes to send 428 IP data to a destination FC port also with a designated IP address 429 then, the following steps are taken: 430 1. The source port shall consult its local mapping tables to 431 determine the . 432 (Note, WWP_N address and 48-bit MAC address will conceptually 433 mean the same thing in this discussion.) 435 2. If such a mapping is found, then the source shall send the IP 436 data to the port whose WWP_N address was found in the table. The 437 corresponding destination Port_ID shall first be validated. 439 3. If such a mapping is not found, then the source shall send an 440 ARP broadcast message to its connected FC network in 441 anticipation of getting a reply from the correct destination 442 along with its WWP_N address. 444 4. When an ARP broadcast message is received by the destination it 445 shall generate an ARP response. Since the ARP response must be 446 addressed to a specific destination Port_ID, the FC layer 447 mapping between the MAC address and Port_ID (of the ARP Request 448 orginator) must be valid before the reply is sent. 450 4.2.1 ARP Broadcast in a Point-to-Point Topology 452 There is no requirement for ARP since the WWP_N is known after the 453 two N_Ports carry out a N_Port Login, that is a PLOGI (See Appendix 454 A). 456 4.2.2 ARP Broadcast in a Private Loop Topology 458 In a private loop, the ARP broadcast message is sent using the 459 broadcast method specified in the FC-AL [7]standard. 461 1. The source port shall first send an Open Broadcast 462 Replicate primitive (OPN(fr))Signal forcing all the ports 463 in the loop (except itself), to replicate the frames that 464 they receive while examining the frame header's 465 Destination_ID field. 467 2. The source port shall remove this OPN(fr) signal when it 468 returns to it. 470 3. The loop is now ready to receive the ARP broadcast message 471 and is sent as a broadcast sequence, that is using FC 472 frames. 474 4. The source shall now send a FC frame containing the ARP 475 Request (ARP broadcast message), as a sequence in a Class 3 476 frame with the following FC Header D_ID field and F_CTL bits 477 in the FC header set to: 479 Destination ID: D_ID = 0xFF-FF-FF 481 Sequence Initiative : SI=0 483 Last Sequence : LS=1 485 End Sequence : ES=1. 487 The above FCTL settings apply to single-frame broadcasts, 488 as used in ARP sequences. This information is provided to 489 clarify ARP Broadcast usage only, and should not be 490 interpreted as prohibiting the use of multiframe 491 broadcasts by this specification. 493 5. Compliant ARP broadcast sequences shall include Network Headers 494 with destination MAC address in the Network Header set to 495 0xFF-FF-FF-FF-FF-FF 496 6. The destination port recognizing its IP address in the ARP 497 packet shall respond with an ARP Reply message. 499 4.2.3 ARP Broadcast in a Public Loop Topology 501 The following steps will be followed when a port is configured in a 502 public loop: 504 1. A public loop device attached to a fabric through an FL_Port 505 shall not use the OPN(fr) signal primitive. Rather, it shall 506 send the broadcast sequence to the FL_Port at AL_PA = 0x00. 508 2. A fabric shall propagate the broadcast to all other ports 509 including the FL_Port which the broadcast arrived on. This 510 includes all F_Ports, and other FL_Ports. 512 3. On each FL_Port, the fabric shall first propagate the 513 broadcast by first using the primitive signal OPNfr, in order 514 to prepare the loop to receive the broadcast sequence 516 4. A broadcast sequence is now sent on all ports (all FL_ports, 517 F_Ports)in Class 3 frame with: 519 Destination ID : D_ID = 0xFF-FF-FF 521 Sequence Initiative : SI=0 523 Last Sequence : LS=1 525 End Sequence : ES=1. 527 5. Compliant ARP broadcast sequences shall include Network Headers 528 with destination MAC address in the Network Header set to 529 0xFF-FF-FF-FF-FF-FF 531 6. The destination port recognizing its IP address in the ARP 532 packet shall respond with an ARP Reply message. 534 4.2.4 ARP Operation in a Fabric Topology 536 1. Nodes directly attached to fabric do not require the OPN(fr) 537 primitive signal. 539 2. A broadcast sequence is now sent on all ports (all FL_ports, 540 F_Ports)in Class 3 frame with: 542 Destination ID : D_ID = 0xFF-FF-FF 543 Sequence Initiative : SI=0 545 Last Sequence : LS=1 547 End Sequence : ES=1. 549 3. Compliant ARP broadcast sequences shall include Network Headers 550 with destination MAC address in the Network Header set to 551 0xFF-FF-FF-FF-FF-FF 553 4. The destination port recognizing its IP address in 554 the ARP packet shall respond with an ARP Reply 556 5.0 Mechanisms for Maintaining FC Layer Mappings 558 FC layer mapping between the MAC address and the Port_ID is 559 independent of the ARP mechanism and is more closely associated with 560 the details of the FC protocols. The section presents several 561 possible mechanisms that may be used for maintaining FC-layer 562 mappings, that is, to create and maintain MAC Address to Port Address 563 tables. The preferred method is a configuration and administration 564 issue, and may be implementation-dependent. 566 Each method should have some mechanism to ensure PLOGI has completed 567 successfully before data is sent. A related concern in large networks 568 is limiting concurrent logins to only those ports with active IP 569 traffic. 571 5.1 Login on Cached Mapping Information 573 This method insulates the level performing LOGIN from the level 574 interpreting ARP. It is more accommodating of non-ARP mechanisms for 575 building the FC-layer mapping table. 577 1. Broadcast messages that carry a Network Header contain the 578 S_ID 579 on the FC-header and WWP_N in the Network-header. Caching this 580 information provides a correlation of Port_ID to WWP_N. 581 If the received Broadcast message is compliant with this 582 specification, the WWP_N will be the MAC Address. This method 583 may also accommodate other NAA types. 585 2. The WWP_N is "available" if Login has been performed to the 586 Port_ID and flagged. If login has not been performed, the 587 WWP_N 588 is "unavailable". 590 3. If an outbound packet is destined for a port that is 591 "unavailable", the cached information is used to look up the 592 Port_ID. 594 4. After sending an ELS PLOGI command (Port Login) to the Port, 595 wait. By waiting for an outbound packet before initiating 596 login, login resources are reserved only for those ports which 597 wish to establish communication. 599 5. After Port Login completes (ACC received), the outbound packet 600 can be forwarded. At this point in time, both ends have the 601 necessary information to complete their association. 604 5.2 Login on ARP Parsing 606 This method performs LOGIN sooner by parsing ARP before passing it up 607 to higher levels for IP/MAC Address correlation. It requires a low- 608 level awareness of the IP address, and is therefore protocol- 609 specific. 611 1. When an ARP Broadcast Message is received, extract the S_ID 612 from the FC header and the corresponding 613 Network_Source_Address from the Network Header. 615 2. Parse the ARP payload to determine if (a) you are the target 616 of the ARP request (Target IP Address match), and (b) you are 617 currently logged in with the port (Port_ID = S_ID) originating 618 the ARP broadcast. 620 3. Pass the ARP to higher level for ARP Response generation. 622 4. If a Port Login is required, an ELS PLOGI command (Port Login) 623 is sent immediately to the Port originating the ARP Broadcast. 625 5. After Port Login completes, an ARP response can be forwarded. 626 Note that there are two possible scenarios: 628 - The ACC to PLOGI returns before the ARP reply is processed 629 and the ARP Reply is immediately forwarded. 630 - The ARP reply is delayed, waiting for ACC (successful 631 Login). 633 6. At this point in time, both ends have the necessary 634 information to complete their 635 association. 637 5.3 Use of Name Server 639 This method is preferred in environments where a Name Server is 640 required [4]. Compliant topologies require a Name Server, while [5] 641 devices may not be able to access the well-known Name Server address, 642 even if one exists. 644 1. A Name Server may be referenced to resolve unmapped MAC 645 addresses. 647 2. Any upper layer send request for which there is not a 648 Port_ID to MAC address mapping can trigger a query to a name 649 server. 651 3. The format of the Name Server query and response is outside 652 the scope of this document. See FC-FLA [4] for a typical 653 example. 655 4. A preferred Name Server implementation is described in 656 [ns008.pdf on ftp.network.com]. The MAC address must be 657 re-formatted in the 64-bit WWP_N format before the query is 658 issued. 660 5. The query response from the Name Server must contain the 661 Port_ID associated with the MAC Address specified in the 662 query. 664 6. Send an ELS PLOGI command (Port Login) to the Port. 666 7. After Port Login completes, the outbound packet can be 667 forwarded. 669 8. At this point in time, both ends have the necessary 670 information to complete their . 673 5.4 Login to Everyone 675 In Fibre Channel topologies with a limited number of ports, it may be 676 efficient to unconditionally login to each port. This method is 677 discouraged in fabric and public loop environments. 679 After Port Login completes, the MAC Address to Port_ID Address tables 680 can be constructed. 682 5.5 Static Table 684 In some loop environments with a limited number of ports, a static 685 mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be 686 maintained. The FC layer will always know the destination Port_ID 687 based on the table. The table is typically downloaded into the driver 688 at configuration time. This method scales poorly, and is therefore 689 not recommended. 691 5.6 FARP 693 The Fibre Channel Address Resolution Protocol (FARP) is a method 694 using ELS commands to resolve mapping in environments 695 without a Name Server. That is, when the WWP_N is known, but not the 696 D_ID and a Name Server service doesn't exist. This situation arises, 697 for instance, when Login tables entries expire. 699 The FARP Extended Link Service Request shall resolve Port_IDs of 700 communicating Fibre Channel devices. A FARP Request can be used to 701 retrieve a specific N_Port's current Port_ID given the unique WWP_N 702 and WWN_N. This is accomplished by requesting either a FARP Response 703 ELS command, or by indicating that the Responder N_Port shall perform 704 a login with the FARP Originator. 706 Protocol: 708 FARP Request Sequence (ELS broadcast) 710 No Reply Sequence 712 FARP Response Sequence (ELS command) 714 Accept Reply Sequence 716 Format: FT-1 718 Addressing: 720 - For a FARP Request, The S_ID designates the Originator 721 N_Port requesting addressing information. The D_ID is the 722 broadcast identifier, 0xFF-FF-FF. 724 - For a FARP Response, the S_ID designates the N_Port ID of the 725 device matching the Responder Address Information in the FARP 726 Request. The D_ID is the N_Port ID of the device that initiated 727 the FARP request. 729 Payload: The format of the FARP Request payload is as follows: 731 +-----------------------------------------+---------+ 732 | FARP Request Payload | | 733 +-----------------------------------------+---------+ 734 | Field | Size | 735 | |(Bytes) | 736 +-----------------------------------------+---------+ 737 | 0x54-00-00-00 | 4 | 738 +-----------------------------------------+---------+ 739 | Responder Flags | 1 | 740 +-----------------------------------------+---------+ 741 | Port_ID of Originator | 3 | 742 +-----------------------------------------+---------+ 743 |WWP_N of Originator | 8 | 744 +-----------------------------------------+---------+ 745 |WWN_N of Originator | 8 | 746 +-----------------------------------------+---------+ 747 |WWP_N of Responder | 8 | 748 +-----------------------------------------+---------+ 749 |WWN_N of Responder | 8 | 750 +-----------------------------------------+---------+ 752 The "WWP_N of Responder" and "WWN_N of Responder" fields should be 753 filled in with the Node and Port Names of the desired Responder, 754 while the Responder Flags define what action the Responder should 755 take. The FARP Request Originator can supply the WWP_N of the 756 Responder, the WWN_N of the Responder, or both. Corresponding bits 757 in the "Responder Flags" field should also be set. 759 WWP_N in FARP is the 8-byte WWP_N of the Originator / Responder to 760 the FARP request. 762 WWN_N in FARP is the 8-byte WWN_N of the Originator / Responder to 763 the FARP request. 765 Port_ID: is the 24-bit Port_ID used in the S_ID field of the FARP 766 Request or FARP Response header. 768 Responder Flags: is an 8-bit field (bits 0-7) that defines the action 769 of the Responder. This field is only valid in a FARP Request. 771 Table below indicates the action performed for each bit. If no bits 772 are set, the Responder will take no action. 774 +----------+-------------------------------------------------------+ 775 | | FARP Responder Flag | 776 +----------+--------------+----------------------------------------+ 777 | Bit | Bit Name | Action | 778 | Position | | | 779 +----------+--------------+----------------------------------------+ 780 | 0 | MATCH_PORT | Match on WWP_N of Responder | 781 +----------+--------------+----------------------------------------+ 782 | 1 | MATCH_NODE | Match on WWN_N of Responder | 783 +----------+--------------+----------------------------------------+ 784 | 2 | INIT_PLOGI | Initiate P_LOGI to the Originator | 785 +----------+--------------+----------------------------------------+ 786 | 3 | INIT_FARPR | Send FARP Response ELS to Originator | 787 +----------+--------------+----------------------------------------+ 788 | 4 | Reserved | | 789 +----------+--------------+----------------------------------------+ 790 | 5 | Reserved | | 791 +----------+--------------+----------------------------------------+ 792 | 6 | Reserved | | 793 +----------+--------------+----------------------------------------+ 794 | 7 | Reserved | | 795 +----------+--------------+----------------------------------------+ 797 FARP Request is an ELS broadcast command. You do not have to be 798 logged in to issue a FARP request. 800 Possible Responder Actions: 802 Port Login (P_LOGI) 803 Sent to the Port Identified by " Originator Port_ID" field 804 when responder bit 2 (INIT_PLOGI) == binary '1' 806 FARP Response (FARP) Sequence 808 Sent to the Port Identified by "Originator Port_ID" field 809 when responder bit 3 (INIT_FARPR) == binary '1' 811 Recipients of the FARP Request ELS shall not issue a Service Reject 812 (LS_RJT) if FARP is not supported. 814 For each recipient of the FARP Request Broadcast ELS, the recipients 815 WWN_N and/or WWP_N is matched against the "WWN_N of Responder" and 816 "WWP_N of Responder" fields based on the Responder Flags. 818 If the MATCH_PORT bit is set, the Responder WWP_N is compared with 819 the recipients WWP_N. 821 If the MATCH_NODE bit is set, the Responder WWN_N is compared with 822 the recipients WWN_N. 824 If both bits are set, both are compared, and both have to match. If 825 no match is made, the sequence is ignored and no action is taken. If 826 there is a match, the "Responder Flags" field defines what action to 827 take. This logic is shown in the following table: 829 +-------------------+-------------------+-------------------+ 830 | Compare | MATCH_PORT | MATCH_NODE | 831 +-------------------+-------------------+-------------------+ 832 | Ignore | 0 | 0 | 833 +-------------------+-------------------+-------------------+ 834 | Compare | | | 835 | Responder WWP_N | 1 | 0 | 836 | with | | | 837 | Recipient WWP_N | | | 838 +-------------------+-------------------+-------------------+ 839 | Compare | | | 840 | Responder WWN_N | 0 | 1 | 841 | with | | | 842 | Recipient WWN_N | | | 843 +-------------------+-------------------+-------------------+ 844 | Compare | | | 845 | Responder WWP_N & | | | 846 | WWN_N | 1 | 1 | 847 | with | | | 848 | Recipient WWP_N | | | 849 | & WWN_N | | | 850 +-------------------+-------------------+-------------------+ 852 FARP Response is an ELS command directed to the Originator of the 853 FARP Request. You do not have to be logged in to the FARP Request 854 Originator to issue a FARP Response. 856 Reply Link Service Sequence: 858 Service Reject (LS_RJT) 859 Signifies rejection of the FARP Response command 861 Accept (ACC) Reply Sequence 862 Signifies successful completion of the FARP Response 863 command 864 The format of the FARP Response payload is as follows: 865 +-----------------------------------------+---------+ 866 | FARP Response Payload | | 867 +-----------------------------------------+---------+ 868 | Field | Size | 869 | | (Bytes) | 870 +-----------------------------------------+---------+ 871 | 0x54-01-00-00 | 4 | 872 +-----------------------------------------+---------+ 873 | Reserved | 1 | 874 +-----------------------------------------+---------+ 875 | Port_ID of Responder | 3 | 876 +-----------------------------------------+---------+ 877 |WWP_N of Originator (FARP Request) | 8 | 878 +-----------------------------------------+---------+ 879 |WWN_N of Originator (FARP Request) | 8 | 880 +-----------------------------------------+---------+ 881 |WWP_N of Responder | 8 | 882 +-----------------------------------------+---------+ 883 |WWN_N of Responder | 8 | 884 +-----------------------------------------+---------+ 886 Accept Payload: 888 The format of the FARP Accept payload is as follows: 890 +-----------------------------------------+---------+ 891 | FARP Response Accept Payload | | 892 +-----------------------------------------+---------+ 893 | Field | Size | 894 | |(Bytes) | 895 +-----------------------------------------+---------+ 896 | x02-00-00-00 | 4 | 897 +-----------------------------------------+---------+ 899 6.0 FC layer Address Validation 901 At all times, the mapping has to be validated 902 before use. There are many events that can invalidate this mapping. 903 The following discussion addresses conditions when such a validation 904 is required. 906 6.1 General Discussion 908 After a link interruption occurs, the Port_ID of a port may change. 909 After the interruption, the Port_IDs of all other ports that have 910 previously performed PLOGI (N_Port Login) with this port may have 911 changed, and its own Port_ID may have changed. 913 Because of this, address validation is required after a LIP in a loop 914 topology [7]or after NOS/OLS in a point-to-point topology [6]. 916 Port_IDs will not change as a result of Link Reset(LR),thus address 917 validation is not required. 919 In addition to actively validating devices after a link interruption, 920 if a port receives any FC-4 data frames (other than broadcast 921 frames), from a port that is not currently logged in, then it shall 922 send an explicit Extended Link Service (ELS) Request logout (LOGO) 923 command to that port. 925 ELS commands (Requests and Replies) are used by an N_Port to solicit 926 a destination port (F_Port or N_Port) to perform some link-level 927 function or service.) The LOGO Request is used to request 928 invalidation of the service parameters and Port_ID of the recipient 929 N_Port. 931 The level of initialization and subsequent validation and recovery 932 reported to the upper (FC-4) layers is implementation-specific. 934 In general, an explicit Logout (LOGO) shall be sent whenever the FC- 935 Layer mapping between the Port_ID and WWP_N of a remote port is 936 removed. 938 The effect of power-up or re-boot on the mapping tables is outside 939 the scope of this specification. 941 6.2 FC Layer Address Validation in a Point-to-Point Topology 943 No validation is required after LR. In a point-to-point topology, 944 NOS/OLS causes implicit logout of each port and after a NOS/OLS, each 945 port must perform a PLOGI [2]. 947 6.3 FC Layer Address Validation in a Private Loop Topology 949 After a LIP, a port shall not transmit any link data to another port 950 until the address of the other port has been validated. The 951 validation consists of completing either ADISC or PDISC. (See 952 Appendix A) 954 ADISC (Address Discovery) is an ELS command for discovering the hard 955 addresses - the 24-bit NL_port identifier- of N_Ports [5], [6]. 957 PDISC (Discover Port) is an ELS command for exchanging service 958 parameters without affecting login state [5], [6]. 960 As a requester, this specification prohibits PDISC and requires 961 ADISC. 963 As a responder, an implementation may need to respond to both ADISC 964 and PDISC for compatibility with other FC specifications. 966 If the three addresses, Port_ID, WWP_N, WWN_N, exactly match the 967 values prior to the LIP, then any active exchanges may continue. 969 If any of the three addresses have changed, then the node must be 970 either implicitly or explicitly logged out [4], [5]. 972 6.4 FC Layer Address Validation in a Public Loop Topology 974 After a LIP, each public loop port shall not transmit any frame until 975 it receives the FAN ELS from the fabric [4]. 977 A FAN (Fabric Address Notification) ELS command is sent by the fabric 978 to all known previously logged in ports following an initialization 979 event. 981 The WWP_N and WWN_N of the fabric FL_Port contained in the FAN ELS 982 must exactly match the values before the LIP. In addition, the AL_PA 983 obtained by the port must be the same as the one before the LIP. 985 If the above conditions are met, the port may resume all exchanges. 986 If not, then FLOGI (Fabric login) must be performed with the fabric 987 and all nodes must be either implicitly or explicitly logged out. 989 A public loop device will have to perform the private loop 990 authentication to any nodes on the local loop which have an Area + 991 Domain Address == 0x00-00-XX 993 6.5 FC Layer Address Validation in a Fabric Topology 995 No validation is required after LR (link reset). 997 After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID 998 of the port, the WW Port Name of the fabric, and the WWN_N of the 999 fabric are the same as before the NOS/OLS, then the port may resume 1000 all exchanges. If not, all nodes must be either, implicitly or 1001 explicitly, logged out [2]. 1003 7. Exchange Management 1005 7.1 Exchange Origination 1007 FC Exchanges shall be established to transfer data between ports. 1008 Frames on IP exchanges shall not transfer Sequence Initiative. 1010 7.2 Exchange Termination 1012 With the exception of the recommendations in Appendix C, "Reliability 1013 in Class 3", the mechanism for aging or expiring exchanges based on 1014 activity, timeout, or other method is outside the scope of this 1015 document. 1017 Exchanges may be terminated by either port. 1019 The Exchange Originator shall normally terminate Exchanges by setting 1020 the LS bit, following normal FC standard FC-PH [2] rules. This 1021 specification prohibits the use of the NOP ELS with LS set for 1022 Exchange termination. 1024 Exchanges may be torn down by the Exchange Responder by using the 1025 ABTS_LS protocol. The use of ABTS_LS for terminating aged exchanges 1026 or error recovery is outside the scope of this document. 1028 The termination of IP exchanges by Logout is discouraged, since this 1029 may terminate active exchanges on other FC-4s. 1031 8. Summary of Supported Features 1033 Note: 'Required' means the feature support is mandatory, 'Prohibited' 1034 means the feature support is not allowed, 'Allowed' means the feature 1035 support is optional, and 'Settable' means support is as specified in 1036 the relevant standard. 1038 8.1 FC-4 Header (Note 1) 1039 +--------------------------------------------------------------------+ 1040 | Feature | Support | Notes | 1041 +--------------------------------------------------------------------+ 1042 | Type Code ( = 5) ISO8802-2 LLC/S | Required | 2 | 1043 | Network Headers | Required | 3 | 1044 | Other Optional Headers | Prohibited | | 1045 +--------------------------------------------------------------------+ 1046 Notes: 1048 1. This table applies only to FC-4 related data, such as IP and 1049 ARP packets. This table does not apply to link services and 1050 other non-FC-4 sequences (PLOGI, for example) that must occur 1051 for normal operation. 1053 2. The TYPE field in the FC Header (Word 2 bits 31-24) must 1054 indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This 1055 revision of the document focuses solely on the issues related 1056 to running IP and ARP over FC. All other issues are outside 1057 the scope of this document, including full support for IEEE 1058 802.2 LLC. 1060 3. DF_CTL field (Word 3, bits 23-16 of FC-Header)must indicate 1061 the presence of a Network Header (0010 0000) on the First 1062 logical Frame of FC-4 sequences. 1064 8.2 R_CTL (FC-Header Word 0, bits 31-14) 1066 +--------------------------------------------------------------------+ 1067 | Feature | Support | Notes | 1068 +--------------------------------------------------------------------+ 1069 | Information Category (R_CTL Routing): | | | 1070 | FC-4 Device Data | Required | 1 | 1071 | Extended Link Data | Required | 2 | 1072 | FC-4 Link Data | Prohibited | | 1073 | Video Data | Prohibited | | 1074 | Basic Link Data | Required | 3 | 1075 | Link Control | Required | 4 | 1076 | R_CTL information | | | 1077 | Uncategorized | Prohibited | | 1078 | Solicited Data | Prohibited | | 1079 | Unsolicited Control | Required | 2 | 1080 | Solicited Control | Required | 2 | 1081 | Unsolicited Data | Required | 1 | 1082 | Data Descriptor | Prohibited | | 1083 | Unsolicited Command | Prohibited | | 1084 | Command Status | Prohibited | | 1085 +--------------------------------------------------------------------+ 1086 Notes: 1087 1. This is required for FC-4 (IP and ARP) packets 1088 - Routing bits of R_CTL field must indicate Device Data 1089 frames (0000). 1090 - Information Category of R_CTL field must indicate 1091 Unsolicited Data (0100). 1092 2. This is required for Extended Link Services. 1094 3. This is required for Basic Link Services. 1096 4. This is required for Link Control frames. 1098 8.3 F_CTL (FC-Header Word 2, bits 23-0) 1099 +--------------------------------------------------------------------+ 1100 | Feature | Support | Notes | 1101 +--------------------------------------------------------------------+ 1102 | Exchange Context | Settable | | 1103 | Sequence Context | Settable | | 1104 | First / Last / End Sequence (FS/LS/ES) | Settable | | 1105 | Chained Sequence | Prohibited | | 1106 | Sequence Initiative (SI) | Settable | 1 | 1107 | X_ID Reassigned / Invalidate | Prohibited | | 1108 | Unidirectional Transmit | Settable | | 1109 | Continue Sequence Condition | Required | 2 | 1110 | Abort Seq. Condition -continue and single seq.| Required | 3 | 1111 | Relative Offset - Unsolicited Data | Settable | 4 | 1112 | Fill Bytes | Settable | | 1113 +--------------------------------------------------------------------+ 1115 Notes: 1117 1. For FC-4 frames, each N_Port shall have a dedicated X_ID for 1118 sending data to each N_Port in the network and a dedicated 1119 X_ID for receiving data from each N_Port as well. Exchanges 1120 are used in a unidirectional mode, thus setting sequence 1121 initiative is not valid for FC-4 frames. Sequence initiative 1122 is valid when using Extended Link Services. 1124 2. This field is required to be 00, no information. 1126 3. Sequence error policy is requested by an exchange originator 1127 in the F_CTL Abort Sequence Condition bits in the first data 1128 frame of the exchange. For classes 1 and 2, ACK frame is 1129 required to be "continuous sequence". 1131 4. Relative offset prohibited on all other types (Information 1132 Category) of frames. 1134 8.4 Sequences 1135 +---------------------------------------------------------------------+ 1136 | Feature | Support |Notes | 1137 +---------------------------------------------------------------------+ 1138 | Class 2 open sequences / exchange | 1 | 1 | 1139 | Length of seq. not limited by end-to-end credit | Required | 2 | 1140 | Maximum sequence size - IP sequences | 65536 | 3 | 1141 | Maximum sequence size - ARP sequences | 532 | 4 | 1142 | Capability to receive sequence of maximum size | Allowed | 5 | 1143 | Sequence Streaming | Prohibited | 6 | 1144 | Stop Sequence Protocol | Prohibited | | 1145 | ACK_0 support | Allowed | 7 | 1146 | ACK_1 support | Required | 7 | 1147 | ACK_N support | Prohibited | | 1148 | Class of Service for transmitted sequences | 1, 2 or 3 | 8 | 1149 | Continuously Increasing Sequence Count | Allowed | 9,10 | 1150 +---------------------------------------------------------------------+ 1151 Notes: 1153 1. Only one active sequence per exchange is allowed. 1155 2. A sequence initiator shall be capable of transmitting 1156 sequences containing more frames than the available credit 1157 indicated by a sequence recipient at login. FC-PH [2] end-to 1158 end flow control rules will be followed when transmitting such 1159 sequences. 1161 3. Maximum sequence size is 65536 bytes. Thus the maximum IP 1162 packet size (MTU) is 65280 bytes (65536 - 256 bytes for header 1163 overhead). 1165 4. Maximum size ARP packet is 532 bytes (including LLC/SNAP 1166 headers). 1168 5. Some OS environments may not handle the max MTU of 65536. It 1169 is up to the administrator to configure the Max MTU for all 1170 systems. 1172 6. All class 3 sequences are assumed to be non-streamed. 1174 7. Only applies for Class 1 and 2. Use of ACK_1 is default, 1175 ACK_0 used if indicated by sequence recipient at login. 1177 8. The administrator configured class of service is used, except 1178 where otherwise specified (e.g. Broadcasts are always sent in 1179 class 3). 1181 9. Review Appendix C, "Reliability in Class 3". 1183 10. The first frame of the first sequence of anew exchange must 1184 have SEQ_CNT = 0 [2]. 1186 8.5 Exchanges 1187 +--------------------------------------------------------------------+ 1188 | Feature | Support | Notes | 1189 +--------------------------------------------------------------------+ 1190 | X_ID interlock support | Allowed | 1 | 1191 | OX_ID=FFFF | Prohibited | | 1192 | RX_ID=FFFF | Allowed | 2 | 1193 | Action if no exchange resources available | P_RJT | 3 | 1194 | Long Lived Exchanges | Allowed | 4 | 1195 | Reallocation of Idle Exchanges | Allowed | | 1196 +--------------------------------------------------------------------+ 1198 Notes: 1200 1. Only applies to Classes 1 and 2, supported by the exchange 1201 originator. A Port shall be capable of interoperating with 1202 another Port that requires X_ID interlock. The exchange 1203 originator facility within the Port shall use the X_ID 1204 Interlock protocol in such cases. 1206 2. An exchange responder is not required to assign RX_IDs. If a 1207 RX_ID of FFFF is assigned, it is identifying exchanges based 1208 on S_ID / D_ID / OX_ID only. 1210 3. In Classes 1 and 2, a Port shall reject a frame that would 1211 create a new exchange with a P_RJT containing reason code 1212 "Unable to establish exchange". In Class 3, the frame would be 1213 dropped. 1215 4. When an exchange is created between 2 Ports for IP/ARP data, 1216 it remains active while the ports are logged in with each 1217 other. An exchange shall not transfer Sequence Initiative 1218 (SI). Broadcasts and ELS commands may use short lived 1219 exchanges. 1221 8.6 ARP 1222 +--------------------------------------------------------------------+ 1223 | Feature | Support | Notes | 1224 +--------------------------------------------------------------------+ 1225 | ARP Server Support | Prohibited | 1 | 1226 | Response to ARP requests | Required | 2 | 1227 | ARP requests transmitted as broadcast message | Required | | 1228 | Class of Service for ARP requests | 3 | 3 | 1229 | Class of Service for ARP replies | 1, 2 or 3 | 4 | 1230 +--------------------------------------------------------------------+ 1232 Notes: 1234 1. Well-known Address FFFFFC is not used for ARP requests. Frames 1235 from Well-known Address FFFFFC are not considered to be ARP 1236 frames. Broadcast support is required for ARP. 1238 2. The IP Address is mapped to a specific MAC address with ARP. 1240 3. An ARP request is a broadcast message, thus Class 3 is always 1241 used. 1243 4. An ARP reply is a normal sequence, thus the administrator 1244 configured class of service is used. 1246 8.7 Extended Link Services (ELS) 1247 +--------------------------------------------------------------------+ 1248 | Feature | Support | Notes | 1249 +--------------------------------------------------------------------+ 1250 | Class of service for ELS commands / responses | 1,2 or 3 | 1 | 1251 | Explicit N-Port Login | Required | | 1252 | Explicit F-Port Login | Required | | 1253 | FLOGI ELS command | Required | | 1254 | PLOGI ELS command | Required | | 1255 | ADISC ELS command | Required | | 1256 | PDISC ELS command | Allowed | 2 | 1257 | FAN ELS command | Required | 3 | 1258 | LOGO ELS command | Required | | 1259 | Other ELS command support | Allowed | 4 | 1260 +--------------------------------------------------------------------+ 1262 Notes: 1264 1. The administrator configured class of service is used. 1266 2. PDISC is prohibited as requester. ADISC should be used 1267 instead. As a responder, an implementation may need to respond 1268 to both ADISC and PDISC for compatibility with other 1269 specifications. 1271 3. FAN is required in a public loop environment. 1273 4. If other ELS commands are received an LS_RJT may be sent. NOP 1274 is not required by this specification, and should not be used 1275 as a mechanism to terminate exchanges. 1277 8.8 Login Parameters 1279 Unless explicitly noted here, a compliant implementation shall use 1280 the login parameters as described in [4]. 1282 8.8.1 Common Service Parameters - FLOGI 1284 - FC-PH Version, lowest version may be 0x09 to indicate 1285 'minimum 4.3'. 1287 - Can't use BB_Credit=0 for N_Port on a switched Fabric 1288 (F_Port). 1290 8.8.2 Common Service Parameters - PLOGI 1292 - FC-PH Version, lowest version may be 0x09 to indicate 1293 'minimum 4.3'. 1295 - Can't use BB_Credit=0 for N_Port in a Point-to-Point 1296 configuration 1298 - Random Relative Offset is allowed. 1300 - Note that the 'Receive Data Field Size' fields specified in 1301 the PLOGI represent both optional headers and payload. 1303 - The MAC Address can therefore be extracted from the 6 lower 1304 bytes of the WWP_N field (when the IEEE 48-bit Identifier 1305 format is chosen as the NAA) during PLOGI or ACC payload 1306 exchanged during Fibre Channel Login [2]. 1308 - The MAC Address can also be extracted from the WWP_N field in 1309 the Network Header during ADISC (and ADISC ACC), or PDISC 1310 (and PDISC ACC). 1312 8.8.3 Class 3 Service Parameters - PLOGI 1314 - Discard error policy only. 1316 ACKNOWLEDGEMENT 1318 This specification is based on FCA IP Profile, Version 3.3. The FCA 1319 IP Profile was a joint work of the Fibre Channel Association (FCA) 1320 vendor community. The following companies and organizations have 1321 contributed to the creation of the FCA IP Profile: Adaptec, Ancor, 1322 Brocade, Clarion, Crossroads, emf Associates, Emulex, Finisar, 1323 Gadzoox, Hewlett Packard, Interphase, Jaycor, LLNL, McData, Migration 1324 Associates, Prisa, Q-Logic, Symbios, Systran, Tektronix, Univ. of 1325 Minnesota, Univ. of New Hamshire. 1327 REFERENCES 1329 [1] FCA IP Profile, Revision 2.3, May 15, 1997 1331 [2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI 1332 X3.230-1994 1334 [3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1335 1996 1337 [4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.4, October 1338 21, 1996 1340 [5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), 1341 Rev.1.7, October 7, 1996 1343 [6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), 1344 Rev. 7.4, ANSI X3.297-1996 1346 [7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996 1348 [8] Postel, J. and Reynolds, J., "A standard for the Transmission of 1349 IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, Feb, 1988 1351 [9] Plummer, D. "An Ethernet Address Resolution Protocol -or- 1352 Converting Network Addresses to 48-bit Ethernet Address for 1353 Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, Nov 1354 1982. 1356 [10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995 1358 [11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), 1359 Rev. 9.1, ANSI X3.xxx-199x 1361 [12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", 1362 Ancot Corporation 1364 [13] Fibre Channel -Gigabit Communications and I/O for Computers 1365 Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2 1367 AUTHORS' ADDRESSES 1368 Murali Rajagopal 1369 Gadzoox Networks, Inc. 1370 711 Kimberly Avenue, Suite 100 1371 Placentia, CA 92870 1373 Phone: +1 714 577 6805 1374 Fax: +1 714 524 8508 1375 Email: murali@gadzoox.com 1377 Raj Bhagwat 1378 Gadzoox Networks, Inc. 1379 711 Kimberly Avenue, Suite 100 1380 Placentia, CA 92870 1382 Phone: +1 714 577 6806 1383 Fax: +1 714 524 8508 1384 Email: raj@gadzoox.com 1386 Wayne Rickard 1387 Gadzoox Networks, Inc. 1388 711 Kimberly Avenue, Suite 100 1389 Placentia, CA 92870 1391 Phone: +1 714 577 6803 1392 Fax: +1 714 524 8508 1393 Email: wayne@gadzoox.com 1395 APPENDIX - A 1397 FIBRE CHANNEL OVERVIEW 1399 A.1 Brief Tutorial 1401 FC standard [2] defines 4 "levels" (not layers) for its protocol description: FC-0, 1402 FC-1, FC-2, FC-3, and FC-4. The first three levels (FC-0, FC-1, FC-2) 1403 are largely concerned with the physical formatting and control aspects 1404 of the protocol. FC-3 is architecturally defined but not unspecified at this time. 1405 FC-4 is meant for supporting profiles of higher protocols such as IP and 1406 Small Computer Serial Interface (SCSI) and supports a relatively small 1407 set of higher level protocols compared to LAN protocols such as IEEE 1408 802.3. 1410 FC devices are called "Nodes", each of which has at least one "Port" to 1411 connect to other ports. A Node may be a workstation, a disk drive or 1412 disk array, a camera, a display unit, etc. The set of hardware components, 1413 and transreceivers, connecting two or more node ports is called a topology. 1415 A "Link" is two unidirectional paths flowing in opposite directions and 1416 connecting two Ports within adjacent Nodes. 1418 FC Nodes communicate using these higher layer protocols such as SCSI and IP 1419 over FC and are configured to operate using one of the following 1420 networking topologies: 1421 - Point-to-Point 1422 - Private Loop 1423 - Public Loop (attachment to a Fabric) 1424 - Fabric 1425 The point-to-point is the simplest of the four topologies, where only 1426 two nodes communicate with each other. The private loop may connect a 1427 number of devices (max 126) in a logical ring much like Token Ring and 1428 is distinguished from a public loop by the absence of a Fabric Node 1429 participating in the loop. The Fabric topology is a switched network 1430 where any attached node can communicate with any other. 1432 Table below summarizes the usage of port types depending on its location 1433 [12]: 1435 +-----------+-------------+-----------------------------------------+ 1436 | Port Type | Location | Topology Associated with | 1437 +-----------+-------------+-----------------------------------------+ 1438 | N_Port | Node | Point-to-Point or Fabric | 1439 +-----------+-------------+-----------------------------------------+ 1440 | NL_Port | Node |In N_Port mode -Point-to-Point or Fabric | 1441 | | |In NL_Port mode - Arbitrated Loop | 1442 +-----------+-------------+-----------------------------------------+ 1443 | F_Port | Fabric | Fabric | 1444 +-----------+-------------+-----------------------------------------+ 1445 | FL_Port | Fabric | In F_Port mode - Fabric | 1446 | | | In FL_Port mode - Arbitrated Loop | 1447 +-----------+-------------+-----------------------------------------+ 1448 | E_Port | Fabric | Internal Fabric Expansion | 1449 +-----------+-------------+-----------------------------------------+ 1450 | G_Port | Fabric | In F_Port mode - Fabric | 1451 | | | In E_Port mode - Internal Fabric Expan.| 1452 +-----------+-------------+-----------------------------------------+ 1453 | GL_Port | Fabric | In F_Port mode - Fabric | 1454 | | | In FL_Port mode - Abritrated Loop | 1455 | | | In E_Port mode - Internal Fabric Expan. | 1456 +-----------+-------------+-----------------------------------------+ 1457 A.2 Fibre Channel Header Fields 1459 Fibre Channel Frame Header, Network Header, and payload carrying IP Packet 1461 +---+----------------+----------------+----------------+--------------+ 1462 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1463 +---+----------------+----------------+----------------+--------------+ 1464 |0 | RTCL | D_ID | 1465 +---+----------------+----------------+----------------+--------------+ 1466 |1 | RSVD | S_ID | 1467 +---+----------------+----------------+----------------+--------------+ 1468 |2 | TYPE | F_CTL | 1469 +---+----------------+----------------+----------------+--------------+ 1470 |3 | SEQ_ID | DF_CTL | SEQ_CNT | 1471 +---+----------------+----------------+----------------+--------------+ 1472 |4 | OX_ID | RX_ID | 1473 +---+----------------+----------------+----------------+--------------+ 1474 |5 | NAA | Network_Dest_Address (MSB) | 1475 +---+----------------+----------------+----------------+--------------+ 1476 |6 | Network_Dest_Address (LSB) | 1477 +---+----------------+----------------+----------------+--------------+ 1478 |7 | NAA | Network_Src_Address (MSB) | 1479 +---+----------------+----------------+----------------+--------------+ 1480 |8 | Network_Src_Address (LSB) | 1481 +---+----------------+----------------+----------------+--------------+ 1482 |9 | DSAP | SSAP | CTRL | OUI | 1483 +---+----------------+----------------+----------------+--------------+ 1484 |10 | OUI | PID | 1485 +---+----------------+----------------+----------------+--------------+ 1486 |11 | IP Packet Data | 1487 +---+----------------+----------------+----------------+--------------+ 1488 |12 | ... | 1489 +---+----------------+----------------+----------------+--------------+ 1491 The FC header as shown in the above diagrams contains routing and other 1492 control information to manage frames, sequences, and exchanges. The 1493 frame header is sent as 6 transmission words immediately following an SOF 1494 delimiter and before the data field. 1496 D_ID and S_ID: 1498 FC uses destination address routing [12], [13]. Frame routing in 1499 a point-to-point topology is trivial. 1501 For the Arbitrated Loop topology, with the destination NL_Port on 1502 the same AL, the source port must pick the destination port, 1503 determine its AL Physical Address, and "Open" the destination 1504 port. The frames must pass through other NL_Ports or the FL_Port 1505 on the loop between the source and destination, but these ports 1506 do not capture the frames. They simply repeat and transmit the 1507 frame. Either communicating port may "Close" the circuit. 1509 When the destination port is not on the same AL, the source 1510 NL_Port must open the FL_Port attached to a Fabric. Once in the 1511 Fabric, the Fabric routes the frames again to the destination. 1513 In a Fabric topology, the Fabric looks into the frame header, 1514 extracts the destination address (D_ID), searches its own routing 1515 tables, and sends the frame to the destination port along the path 1516 chosen. The process of choosing a path may be performed at each 1517 fabric until the F_Port attached to the destination N_Port is 1518 reached. 1520 R_CTL (Routing Control) and TYPE(data structure): 1522 Frames for each FC-4 can be easily distinguished from the others 1523 at the receiving port using the R_CTL (Routing Control) and TYPE 1524 (data structure) fields in the frame header. 1526 The R_CTL has two sub-fields: Routing bits and Information category. 1527 The Routing bits sub-field has specific values that mean FC-4 data 1528 follows and the Information Category tells the receiver the "Type" of 1529 data contained in the frame. The R_CTL and TYPE code points are 1530 shown in the diagrams. 1532 Other Header fields: 1534 F_CTL (Frame Control) and SEQ_ID (Sequence Identification), 1535 SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), 1536 RX_ID (Responder exchange Identifier), and Parameter fields are 1537 used to manage the contents of a frame, and mark information 1538 exchange boundaries for the destination port. 1540 F_CTL(Frame Control): 1542 The FC_CTL field is a 3-byte field that contains information 1543 relating to the frame content. Most of the other frame header 1544 fields are used for frame identification. Among other things, 1545 bits in this field indicate the first sequence, last sequence, or 1546 end sequence. Sequence Initiative bit is used to pass control of 1547 the next sequence in the exchange to the recipient. 1549 SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count): 1551 This is used to uniquely identify sequences within an Exchange. 1552 The uniquely identifies any active sequence. 1553 SEQ_CNT is used to uniquely identify frames within a Sequence to 1554 assure sequentiality of frame reception, and to allow unique 1555 correlation of link control frames with their related data frames. 1557 Originator Exchange Identifier (OX_ID) and Responder Exchange 1558 Identifier (RX_ID): 1560 The OX_ID value provides association of frames with specific 1561 Exchanges originating at a particular N_Port. The RX_ID field 1562 provides the same function that the OX_ID provides for the 1563 Exchange Originator. The OX_ID is meaningful on the Exchange 1564 Originator, and the RX_ID is meaningful on the Responder. 1566 DF_CTL (Data Field Control): 1568 The DF_CTL field specifies the presence or absence of optional 1569 headers between the Frame header and Frame Payload 1571 PARAMETER: 1573 The Parameter field has two meanings, depending on Frame type. 1574 For Link Control Frames, the Parameter field indicates the 1575 specific type of link Link Control frame. For Data frames, this 1576 field contains the Relative Offset value. This specifies an 1577 offset from an Upper Layer Protocol buffer from a base address. 1579 Code Points for FC Frame with IP/ARP packet Data 1581 +---+----------------+----------------+----------------+--------------+ 1582 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1583 +---+----------------+----------------+----------------+--------------+ 1584 | 1 | 0x04 | D_ID | 1585 +---+----------------+----------------+----------------+--------------+ 1586 | 2 | 0x00 | S_ID | 1587 +---+----------------+----------------+----------------+--------------+ 1588 | 3 | 0x05 | F_CTL | 1589 +---+----------------+----------------+----------------+--------------+ 1590 | 4 | SEQ_ID | 0x20 | SEQ_CNT | 1591 +---+----------------+----------------+----------------+--------------+ 1592 | 5 | OX_ID | RX_ID | 1593 +---+----------------+----------------+----------------+--------------+ 1594 | 6 | 0001 | 0x00-00-00 Dest. MAC | 1595 +---+----------------+----------------+----------------+--------------+ 1596 | 7 | Dest. MAC (LSB) | 1597 +---+----------------+----------------+-------------------------------+ 1598 | 8 | 0001 | 0x00-00-00 Src. MAC | 1599 +---+----------------+----------------+----------------+--------------+ 1600 | 9 | Src. MAC (LSB) | 1601 +---+----------------+----------------+----------------+--------------+ 1602 |10 | 0xAA | 0x00 | 0x03 | 0x00 | 1603 +---+----------------+----------------+----------------+--------------+ 1604 |11 | 0x00-00 | 0x08-00 | 1605 +---+----------------+----------------+----------------+--------------+ 1606 |12 | IP/ARP Packet Data | 1607 +---+----------------+----------------+----------------+--------------+ 1608 |13 | ... | 1609 +---+----------------+----------------+----------------+--------------+ 1611 A.3 Acronyms and Glossary of FC Terms 1613 It is assumed that the reader is familiar with the terms and acronyms 1614 used in the FC protocol specification [2]. The following is provided for 1615 easy reference. 1617 A.3.1 Acronyms 1619 First Frame: The frame that contains the SOFi field. This means a logical first and may 1620 not necessarily be the first frame temporally received in a sequence. 1622 Code Point: The coded bit pattern associated with control fields in frames or packets. 1624 PDU: Protocol Data Unit 1626 ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for 1627 aborting an exchange based on the ABTS recipient setting the 1628 Last_Sequence bit in the BA_ACC ELS to the ABTS 1630 ADISC: Discover Address. An ELS for discovering the Hard Addresses (the 1631 24 bit NL_Port Identifier) of N_Ports 1633 D_ID: Destination ID 1635 ES: End sequence. This FCTL bit in the FC header indicates this frame is 1636 the last frame of the sequence. 1638 FAN: Fabric Address Notification. An ELS sent by the fabric to all known 1639 previously logged in ports following an initialization event. 1641 LIP: Loop Initialization. A primitive sequence used by a port to detect 1642 if it is part of a loop or to recover from certain loop errors. 1644 LR: Link reset. A primitive sequence transmitted by a port to initiate 1645 the link reset protocol or to recover from a link timeout. 1647 LS: Last sequence of Exchange. This FCTL bit in the FC header indicates 1648 the sequence is the last sequence of the exchange. 1650 NOS: Not Operational. A primitive sequence transmitted to indicate that 1651 the port transmitting this sequence has detected a link failure or is 1652 offline, waiting for OLS to be received. 1654 OLS: Off line. A primitive sequence transmitted to indicate that the 1655 port transmitting this sequence is either initiating the link 1656 initialization protocol, receiving and recognizing NOS, or entering the 1657 offline state. 1659 PDISC: Discover Port. An ELS for exchanging Service Parameters without 1660 affecting login state. 1662 SI: Sequence Initiative 1664 FLOGI: Fabric Login. 1666 Primitive Sequence: A primitive sequence is an Ordered Set that is 1667 transmitted repeatedly and continuously. 1669 Private Loop Device: A device that does not attempt fabric login (FLOGI) 1670 and usually adheres to PLDA. The Area and Domain components of the 1671 NL_Port ID must be 0x0000. These devices cannot communicate with any 1672 port not in the local loop. 1674 Public Loop Device: A device whose Area and Domain components of the 1675 NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the 1676 device must attempt to open AL_PA 0x00 and attempt FLOGI. These devices 1677 communicate with devices on the local loop as well as devices on the 1678 other side of a Fabric. 1680 Link: Two unidirectional paths flowing in opposite directions and 1681 connecting two Ports within adjacent Nodes. 1683 LOGO: Logout. 1685 Node: A collection of one or more Ports identified by a unique World 1686 Wide Node Name (WW Node Name). 1688 Port: The transmitter, receiver and associated logic at either end of a 1689 link within a Node. There may be multiple Ports per Node. Each Port is 1690 identified by a unique Port_ID, which is volatile, and a unique World 1691 Wide Port Name (WW Port Name), which is unchangeable. In this document, 1692 the term "port" may be used interchangeably with NL_Port or N_Port. 1694 Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. In 1695 a Fibre Channel frame header, the Port_ID is referred to as S_ID (Source 1696 ID) to identify the port originating a frame, and D_ID to identify the 1697 destination port. The Port_ID of a given port is volatile (changeable). 1698 The mechanisms through which a Port_ID may change in a Fibre Channel 1699 topology are outside the scope of this document. 1701 PLOGI: Port Login. 1703 World Wide Port_Name (WWP_N): Fibre Channel requires each Port to have 1704 an unchangeable WWP_N. Fibre Channel specifies a Network Address 1705 Authority (NAA) to distinguish between the various name registration 1706 authorities that may be used to identify the WWP_N. A 4-bit NAA 1707 identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address 1708 together make this a 64-bit field. 1710 World Wide Node_Name (WWN_N): Fibre Channel identifies each Node with a 1711 unchangeable WWN_N. In a single port Node, the WWN_N and the WWP_N may be 1712 identical. 1714 APPENDIX - B 1716 B.1 RELIABILITY IN CLASS 3 1718 Problem: 1719 Sequence ID reuse in Class 3 can conceivably result in missing frame 1720 aliasing with no corresponding detection at the FC2 level. 1722 Prevention: 1723 This specification requires one of the following methods if Class 3 is 1724 used. 1726 - Continuously increasing Sequence Count (new Login Bit) - both 1727 sides must set When an N_Port sets the PLOGI login bit for 1728 continuously increasing SEQ_CNT, it is guaranteeing that it 1729 will transmit all frames within an exchange using a continuously 1730 increasing SEQ_CNT (see description below). 1732 - After using all SEQ_IDs (0-255) once, must start a new Exchange. 1733 It is recommended that a minimum of 4 Exchanges be used before 1734 an OX_ID can be reused. 1736 - Note: If an implementation is not checking the OX_ID when 1737 reassembling sequences, the problem can still occur. Cycling 1738 through some number of SEQ_IDs, then jumping to a new exchange 1739 does not solve the problem. SEQ_IDs must still be unique between 1740 two N_Ports, even across exchanges. 1742 - Use only single-frame Sequences. 1744 B.2 CONTINUOUSLY INCREASING SEQ_CNT 1746 This method allows the recipient to check incoming frames, knowing 1747 exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not 1748 repeat for 65,536 frames, the aliasing problem is significantly reduced. 1750 A login bit (PLOGI) is used to indicate that a device always uses a 1751 continuously increasing SEQ_CNT, even across transfers of sequence 1752 initiative. This bit is necessary for interoperability with some 1753 devices, and it provides other benefits as well. 1755 In the FC-PH-3 [11], the following is supported: 1757 Word 1, bit 17 - SEQ_CNT (S) 1758 0 = Normal FC-PH rules apply 1759 1 = Continuously Increasing SEQ_CNT 1761 Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will 1762 transmit all frames within an exchange using a continuously increasing 1763 SEQ_CNT. Each exchange shall start with SEQ_CNT = 0 in the first frame, 1764 and every frame transmitted after that shall increment the previous 1765 SEQ_CNT by one, even across transfers of sequence initiative. Any frames 1766 received from the other N_Port in the exchange shall have no effect on 1767 the transmitted SEQ_CNT. 1769 [draft-ietf-ipfc-00.txt] 1770 [This INTERNET DRAFT expires on Dec 22, 1998]