RFC 4172
iFCP - A Protocol for Internet Fibre Channel Storage Networking
iFCP - A Protocol for Internet Fibre Channel Storage Networking 🎀
Okay bestie, welcome to RFC 4172 💖 It's a Standards Track document from September 2005, written by a whole squad: C. Monia (Consultant), R. Mullendore (McDATA), F. Travostino (Nortel), W. Jeong (Troika Networks), and M. Edwards (Adaptec (UK) Ltd.). It lives in the Network Working Group ✨ and its title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Status of This Memo
This is an Internet standards track protocol for the Internet community 🌈 It's asking for discussion and suggestions for improvements, so bring your ideas! For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the best part: distribution of this memo is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Okay, the abstract is giving architecture 🔥 This document lays out an architecture and a gateway-to-gateway protocol for running fibre channel fabric functionality over an IP network. That functionality comes from TCP-based protocols for moving fibre channel frames around, plus the distributed fabric services the fibre channel standards describe. The result is that fibre channel devices can talk to each other across gateway-accessed regions, getting the fault isolation of autonomous systems and the scalability of the IP network too. Iconic 👑
Table of Contents
1. Introduction.................................................. 4
1.1. Conventions used in This Document....................... 4
1.1.1. Data Structures Internal to an Implementation... 4
1.2. Purpose of This Document................................ 4
2. iFCP Introduction............................................. 4
2.1. Definitions............................................. 5
3. Fibre Channel Communication Concepts.......................... 7
3.1. The Fibre Channel Network............................... 8
3.2. Fibre Channel Network Topologies........................ 9
3.2.1. Switched Fibre Channel Fabrics.................. 11
3.2.2. Mixed Fibre Channel Fabric...................... 12
3.3. Fibre Channel Layers and Link Services.................. 12
3.3.1. Fabric-Supplied Link Services................... 13
3.4. Fibre Channel Nodes..................................... 14
3.5. Fibre Channel Device Discovery.......................... 14
3.6. Fibre Channel Information Elements...................... 15
3.7. Fibre Channel Frame Format.............................. 15
3.7.1. N_PORT Address Model............................ 16
3.8. Fibre Channel Transport Services........................ 17
3.9. Login Processes......................................... 18
4. The iFCP Network Model........................................ 18
4.1. iFCP Transport Services................................. 21
4.1.1. Fibre Channel Transport Services Supported by
iFCP............................................ 21
4.2. iFCP Device Discovery and Configuration Management...... 21
4.3. iFCP Fabric Properties.................................. 22
4.3.1. Address Transparency............................ 22
4.3.2. Configuration Scalability....................... 23
4.3.3. Fault Tolerance................................. 23
4.4. The iFCP N_PORT Address Model........................... 24
4.5. Operation in Address Transparent Mode................... 25
4.5.1. Transparent Mode Domain ID Management........... 26
4.5.2. Incompatibility with Address Translation Mode... 26
4.6. Operation in Address Translation Mode................... 27
4.6.1. Inbound Frame Address Translation............... 28
4.6.2. Incompatibility with Address Transparent Mode... 29
5. iFCP Protocol................................................. 29
5.1. Overview ............................................... 29
5.1.1. iFCP Transport Services......................... 29
5.1.2. iFCP Support for Link Services.................. 30
5.2. TCP Stream Transport of iFCP Frames..................... 30
5.2.1. iFCP Session Model.............................. 30
5.2.2. iFCP Session Management......................... 31
5.2.3. Terminating iFCP Sessions....................... 39
5.3. Fibre Channel Frame Encapsulation....................... 40
5.3.1. Encapsulation Header Format..................... 41
5.3.2. SOF and EOF Delimiter Fields.................... 44
5.3.3. Frame Encapsulation............................. 45
5.3.4. Frame De-encapsulation.......................... 46
6. TCP Session Control Messages.................................. 47
6.1. Connection Bind (CBIND)................................. 50
6.2. Unbind Connection (UNBIND).............................. 52
6.3. LTEST -- Test Connection Liveness....................... 54
7. Fibre Channel Link Services................................... 55
7.1. Special Link Service Messages........................... 56
7.2. Link Services Requiring Payload Address Translation..... 58
7.3. Fibre Channel Link Services Processed by iFCP........... 61
7.3.1. Special Extended Link Services.................. 63
7.3.2. Special FC-4 Link Services...................... 83
7.4. FLOGI Service Parameters Supported by an iFCP Gateway... 84
8. iFCP Error Detection.......................................... 86
8.1. Overview................................................ 86
8.2. Stale Frame Prevention.................................. 86
8.2.1. Enforcing R_A_TOV Limits........................ 86
9. Fabric Services Supported by an iFCP Implementation........... 88
9.1. F_PORT Server........................................... 88
9.2. Fabric Controller....................................... 89
9.3. Directory/Name Server................................... 89
9.4. Broadcast Server........................................ 89
9.4.1. Establishing the Broadcast Configuration........ 90
9.4.2. Broadcast Session Management.................... 91
9.4.3. Standby Global Broadcast Server................. 91
10. iFCP Security................................................. 91
10.1. Overview................................................ 91
10.2. iFCP Security Threats and Scope......................... 92
10.2.1. Context......................................... 92
10.2.2. Security Threats................................ 92
10.2.3. Interoperability with Security Gateways......... 93
10.2.4. Authentication.................................. 93
10.2.5. Confidentiality................................. 93
10.2.6. Rekeying........................................ 93
10.2.7. Authorization................................... 94
10.2.8. Policy Control.................................. 94
10.2.9. iSNS Role....................................... 94
10.3. iFCP Security Design.................................... 94
10.3.1. Enabling Technologies........................... 94
10.3.2. Use of IKE and IPsec............................ 96
10.3.3. Signatures and Certificate-Based Authentication. 98
10.4. iSNS and iFCP Security.................................. 99
10.5. Use of iSNS to Distribute Security Policy............... 99
10.6. Minimal Security Policy for an iFCP Gateway............. 99
11. Quality of Service Considerations.............................100
11.1. Minimal Requirements....................................100
11.2. High Assurance..........................................100
12. IANA Considerations...........................................101
13. Normative References..........................................101
14. Informative References........................................103
Appendix A. iFCP Support for Fibre Channel Link Services.........105
A.1. Basic Link Services.....................................105
A.2. Pass-Through Link Services..............................105
A.3. Special Link Services...................................107
Appendix B. Supporting the Fibre Channel Loop Topology...........108
B.1. Remote Control of a Public Loop.........................108
Acknowledgements..................................................1091. Introduction ✨
1.1. Conventions Used in This Document
Okay, so the requirement words are where it gets serious 💀 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14, RFC 2119 [RFC2119]. Unless the doc says otherwise, numbers are decimal. 🔢
Also, the diagrams. Every diagram that shows bit and byte ordering (including the structures from the fibre channel standards) follows IETF convention: bit 0 is the most significant bit, and the first addressable byte sits in the upper left corner 🦋 That's different from the INCITS T11 fibre channel standards, where bit 0 is the least significant bit. Don't mix them up, bestie 🙈
1.1.1. Data Structures Internal to an Implementation
This document may define and refer to internal data structures inside an iFCP implementation, so you can talk about required behavior clearly 🧚 These structures are just for explaining things. An implementation doesn't need to actually build them the way this spec describes. Lowkey relief, honestly 💜
1.2. Purpose of This Document
This is a standards-track document 🎀 It specifies a protocol for running fibre channel transport services on a TCP/IP network. Some parts include material from standards controlled by INCITS T10 and T11. That material is only here for informational purposes, and the authoritative information lives in the appropriate NCITS standards document 📚
The authoritative parts of this document are the mapping of standards-compliant fibre channel protocol implementations onto TCP/IP. That mapping covers the sections describing the "iFCP Protocol" (see Section 5). So if you want the real deal, that's the part to focus on 👑
2. iFCP Introduction ✨
okay so iFCP is a gateway-to-gateway protocol 🌐 that gives fibre channel fabric services to fibre channel devices over a TCP/IP network. it uses TCP for congestion control, error detection, and recovery, so it's literally handling the hard stuff for you 💅. its main goal is letting existing fibre channel devices talk to each other at wire speeds over an IP network. no cap, that's iconic 🔥
the protocol and frame address translation method in this doc let you hook fibre channel storage devices up to an IP-based fabric using transparent gateways 🎀
and the transparency is the whole vibe ✨. normal fibre channel frame traffic just passes straight through the gateway, and only when it's needed does the gateway step in to intercept and emulate the fabric services a fibre channel device expects 🫶
2.1. Definitions
okay bestie, here's the glossary of terms we need before anything else 📖
- Address-translation mode -- a gateway mode where N_PORT fabric addresses for locally attached devices are only local to the iFCP gateway region those devices live in 🏠
- Address-transparent mode -- a gateway mode where N_PORT fabric addresses for all fibre channel devices are unique across the bounded iFCP fabric the gateway belongs to 🌍
- Bounded iFCP Fabric -- two or more gateway regions set up to interoperate in address-transparent mode 🤝
- DOMAIN_ID -- the value in the high-order byte of a 24-bit N_PORT fibre channel address 🔢
- F_PORT -- the interface an N_PORT uses to access fibre channel switched-fabric functionality 🔌
- Fabric -- from [FC-FS]: "The entity that interconnects N_PORTs attached to it and is capable of routing frames by using only the address information in the fibre channel frame." 🧠
- Fabric Port -- the interface an N_PORT goes through to reach a fibre channel fabric. the type depends on the fabric topology, but in this spec all fabric port interfaces are treated as functionally equivalent 💖
- FC-2 -- the fibre channel transport services layer, described in [FC-FS] 🚚
- FC-4 -- the fibre channel mapping of an upper-layer protocol, like [FCP-2] (the fibre channel to SCSI mapping) 🗂️
- Fibre Channel Device -- an entity that implements the functionality accessed through an FC-4 application protocol 💾
- Fibre Channel Network -- a native fibre channel fabric plus all of its attached fibre channel nodes 🕸️
- Fibre Channel Node -- a group of one or more N_PORTs controlled by a layer above FC-2. a node attaches to a fibre channel fabric through the N_PORT interface, described in [FC-FS] 🧩
- Gateway Region -- the part of an iFCP fabric that a remotely attached N_PORT reaches through an iFCP gateway. the fibre channel devices in the region are all the ones locally attached to that gateway 🗺️
- iFCP -- the protocol this document is about 💅
- iFCP Frame -- a fibre channel frame encapsulated following the FC Frame Encapsulation Specification [ENCAP] and this specification 🎁
- iFCP Portal -- the point where a logical or physical iFCP device attaches to the IP network. its network address is the IP address plus TCP port number that a request goes to when the TCP connection for an iFCP session is created (see Section 5.2.1) 🚪
- iFCP Session -- an association made up of a pair of N_PORTs and a TCP connection that carries traffic between them. an iFCP session may be created as the result of a PLOGI fibre channel login operation 🤍
- iSNS -- the server functionality and IP protocol that provide storage name services in an iFCP network. fibre channel name services are implemented by an iSNS name server, as described in [ISNS] 📇
- Locally Attached Device -- from a gateway's point of view, a fibre channel device reached through the fibre channel fabric the gateway is attached to 🏡
- Logical iFCP Device -- the abstraction that represents a single fibre channel device as it shows up on an iFCP network 🪞
- N_PORT -- an iFCP or fibre channel entity that represents the interface to fibre channel device functionality. it follows the fibre channel N_PORT semantics specified in [FC-FS]. fibre channel has several variants of this interface depending on fabric topology, and in this document the term covers all of them equally 🔗
- N_PORT Alias -- the N_PORT address a gateway assigns to represent a remote N_PORT that's reached via the iFCP protocol 🎭
- N_PORT fabric address -- an N_PORT's address within the fibre channel fabric 📍
- N_PORT ID -- the address of a locally attached N_PORT within a gateway region. N_PORT IDs get assigned following the fibre channel address assignment rules in [FC-FS] 🆔
- N_PORT Network Address -- an N_PORT's address in the iFCP fabric. it's made of the IP address and TCP port number of the iFCP Portal, plus the N_PORT ID of the locally attached fibre channel device 🏷️
- Port Login (PLOGI) -- the fibre channel Extended Link Service (ELS) that sets up an iFCP session by swapping identification and operation parameters between an originating N_PORT and a responding N_PORT 🤳
- Remotely Attached Device -- from a gateway's point of view, a fibre channel device the gateway reaches by way of the iFCP protocol 🛰️
- Unbounded iFCP Fabric -- two or more gateway regions set up to interoperate in address-translation mode 🌀
3. Fibre Channel Communication Concepts 🧠
fibre channel is a frame-based, serial technology built for peer-to-peer communication between devices. it runs at gigabit speeds with low overhead and low latency, which is giving speed 🏎️💨
this section covers the fibre channel concepts that the iFCP network architecture and protocol in this document are built on. if you already know this stuff, feel free to skip ahead to Section 4 🦋
the material here comes from these T11 specifications:
- The Fibre Channel Framing and Signaling Interface, [FC-FS]
- Fibre Channel Switch Fabric -2, [FC-SW2]
- Fibre Channel Generic Services, [FC-GS3]
- Fibre Channel Fabric Loop Attachment, [FC-FLA]
if you want the deep dive, [KEMCMP] and [KEMALP] are the in-depth treatments of the tech 📚
3.1. The Fibre Channel Network
the fundamental entity in fibre channel is the fibre channel network 🌟. the vibe is different from a layered network architecture. a fibre channel network is mostly defined by its functional elements and the interfaces between them. as shown in Figure 1, those include the following 👀:
- a) N_PORTs -- the end points for fibre channel traffic. in the FC standards, N_PORT interfaces have several variants depending on the topology of the fabric they attach to. in this spec, the term covers any one of those variants 💖
- b) FC Devices -- the fibre channel devices that the N_PORTs give access to 💾
- c) Fabric Ports -- the interfaces inside a fibre channel network that let an N_PORT attach. the types depend on the fabric topology and are discussed in Section 3.2 🔌
- d) the network infrastructure that carries frame traffic between N_PORTs 🛣️
- e) inside a switched or mixed fabric (see Section 3.2), a set of auxiliary servers, including a name server for device discovery and network address resolution. the types of service depend on the network topology 📇
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device |<-------->| Device | | Device |
|........| |........| |........| |........|
| N_PORT | | N_PORT | | N_PORT | | N_PORT |
+---+----+ +----+---+ +----+---+ +----+---+
| | | |
+---+----+ +----+---+ +----+---+ +----+---+
| Fabric | | Fabric | | Fabric | | Fabric |
| Port | | Port | | Port | | Port |
+========+===+========+==========+========+==+========+
| Fabric |
| & |
| Fabric Services |
+-----------------------------------------------------+
Figure 1. A Fibre Channel Networkthe next sections go over the fibre channel network topologies and give you an overview of the fibre channel communications model 🫶
3.2. Fibre Channel Network Topologies
the main fibre channel network topologies are the following 🗺️:
- a) Arbitrated Loop -- a series of N_PORTs connected together in daisy-chain fashion. in [FC-FS], loop-connected N_PORTs are called NL_PORTs. data transmission between NL_PORTs needs arbitration for control of the loop, kind of like a token ring network 🔄
- b) Switched Fabric -- a network made of switching elements, as described in Section 3.2.1 🔀
- c) Mixed Fabric -- a network made of switches and "fabric-attached" loops. you can find a description in [FC-FLA]. a loop-attached N_PORT (NL_PORT) connects to the loop through an L_PORT and reaches the fabric through an FL_PORT 🧵
depending on the topology, the N_PORT and how it attaches to the network can be one of these 👇:
FC Network
Topology Network Interface N_PORT Variant
--------------- ----------------- --------------
Loop L_PORT NL_PORT
Switched F_PORT N_PORT
Mixed FL_PORT via L_PORT NL_PORT
F_PORT N_PORTthe differences between each N_PORT variant and its matching fabric port are only about how the two interact. to an external N_PORT, all fabric ports are invisible, and all remote N_PORTs act functionally identical 🥰✨
3.2.1. Switched Fibre Channel Fabrics ✨
okay so a multi-switch fibre channel fabric is basically a group project where every switch holds hands with the others 🫶 here's how it looks (Figure 2):
+----------+ +----------+
| FC | | FC |
| Device | | Device |
|..........| |..........|
| N_PORT |<........>| N_PORT |
+----+-----+ +-----+----+
| |
+----+-----+ +-----+----+
| F_PORT | | F_PORT |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+ Fibre Channel
|Inter- | |Inter- | Fabric
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+Figure 2. Multi-Switch Fibre Channel Fabric
so the thing connecting the switches is either a proprietary interface 🙄 or the standards-compliant E_PORT interface, which is described in the FC-SW2 specification, [FC-SW2]. the E_PORT is the one that actually plays nice with everybody 💅
3.2.2. Mixed Fibre Channel Fabric
a mixed fabric is when you've got one or more arbitrated loops hooked up to a switched fabric, like in Figure 3 🦋
+----------+ +----------+ +---------+
| FC | | FC | | FC |
| Device | | Device | | Device |
|..........| FC |..........| |.........|
| N_PORT |<........>| NL_PORT +---+ NL_PORT |
+----+-----+ Traffic +-----+----+ +----+----+
| | FC Loop |
+----+-----+ +-----+----+ |
| F_PORT | | FL_PORT +--------+
| | | |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+Figure 3. Mixed Fibre Channel Fabric
as we said before 🔁 the protocol for talking between peer N_PORTs doesn't care about the fabric topology, the N_PORT variant, or what kind of fabric port the N_PORT is plugged into. it's giving independence, literally 😭✨
3.3. Fibre Channel Layers and Link Services
a fibre channel is made up of these layers 🧁
- FC-0 -- The interface to the physical media.
- FC-1 -- The encoding and decoding of data and out-of-band physical link control information for transmission over the physical media.
- FC-2 -- The transfer of frames, sequences, and Exchanges comprising protocol information units.
- FC-3 -- Common Services.
- FC-4 -- Application protocols such as the fibre channel protocol for SCSI (FCP).
on top of those layers, a fibre channel also has a set of auxiliary operations called link services 🎀 some of them run inside the transport layer fabric. they're needed to manage the fibre channel environment, set up communications with other devices, get error info, do error recovery, and provide other similar services. some link services are run by the N_PORT, and others are handled inside the fabric itself. we'll get to those internal ones in the next section 👑
3.3.1. Fabric-Supplied Link Services
okay so there are servers inside a switched fabric that handle certain classes of Link Service requests and service-specific commands 🧚 they show up as N_PORTs sitting at the 'well-known' N_PORT fabric addresses specified in [FC-FS]. requests to them use the normal fibre channel mechanisms for N_PORT-to-N_PORT communications, so no weird special handshake needed 💖
every switched fabric must provide these services:
- Fabric F_PORT server -- Services N_PORT requests to access the fabric for communications.
- Fabric Controller -- Provides state change information to inform other FC devices when an N_PORT exits or enters the fabric (see Section 3.5).
- Directory/Name Server - Allows N_PORTs to register information in a database, retrieve information about other N_PORTs, and to discover other devices as described in Section 3.5.
a switched fabric may also implement these optional services 🌈
- Broadcast Address/Server -- Transmits single-frame, class 3 sequences to all N_PORTs.
- Time Server -- Intended for the management of fabric-wide expiration timers or elapsed time values; not intended for precise time synchronization.
- Management Server - Collects and reports management information, such as link usage, error statistics, link quality, and similar items.
- Quality of Service Facilitator - Performs fabric-wide bandwidth and latency management.
3.4. Fibre Channel Nodes
a fibre channel node has one or more fabric-attached N_PORTs 💜 the node and its N_PORTs come with these identifiers:
a) A worldwide-unique identifier for the node.
b) A worldwide-unique identifier for each N_PORT associated with the node.
c) For each N_PORT attached to a fabric, a 24-bit fabric-unique address with the properties defined in Section 3.7.1. The fabric address is the address to which frames are sent.
every worldwide-unique identifier is a 64-bit binary quantity with the format defined in [FC-FS]. 🔢✨
3.5. Fibre Channel Device Discovery
in a switched or mixed fabric, fibre channel devices and changes in the device configuration may be discovered using services from the fibre channel Name Server and Fabric Controller 🔍
the Name Server is the registration and query crew. it lets a fibre channel device register its presence on the fabric and find out about other devices. for example, one kind of query gets the fabric address of an N_PORT from its 64-bit worldwide-unique name. the full list of supported fibre channel name server queries is specified in [FC-GS3] 📒
the Fabric Controller is the static-discovery sidekick 🦸♀️ it dynamically alerts a fibre channel device whenever an N_PORT is added to or removed from the configuration. devices get these notifications by subscribing to the service, as specified in [FC-FS] 🔔
3.6. Fibre Channel Information Elements
the basic unit of information in fibre channel is the frame 📦 a frame has a fixed header and up to 2112 bytes of payload, with the structure described in Section 3.7. the maximum frame size that can be sent between a pair of fibre channel devices is negotiable up to the payload limit. it depends on the size of the frame buffers in each device and on the path maximum transmission unit (MTU) supported by the fabric 🫧
operations that move information between N_PORT pairs happen through 'Exchanges' 💬 inside an Exchange, information travels in one or more ordered series of frames, which are called Sequences.
an upper layer protocol is defined in terms of transactions carried by Exchanges. each transaction is made of protocol information units, and each one rides along in its own individual Sequence within an Exchange 🎀
3.7. Fibre Channel Frame Format
a fibre channel frame is a header, a payload, and a 32-bit CRC, all wrapped up between SOF and EOF delimiters 🎁 the header holds the control info needed to route frames between N_PORTs and to manage Exchanges and Sequences. here's the frame in diagram form:
Bit 0 31
+-----------------------------+
Word 0 | Start-of-frame Delimiter |
+-----+-----------------------+<----+
| | Destination N_PORT | |
1 | | Fabric Address (D_ID) | |
| | (24 bits) | |
+-----+-----------------------+ 24-byte
| | Source N_PORT | Frame
2 | | Fabric Address (S_ID) | Header
| | (24 bits) | |
+-----+-----------------------+ |
3 | Control information for | |
. | frame type, Exchange | |
. | management, IU | |
. | segmentation and | |
6 | re-assembly | |
+-----------------------------+<----+
7 | |
. | Frame payload |
. | (0 - 2112 bytes) |
. | |
. | |
. | |
+-----------------------------+
. | CRC |
+-----------------------------+
n | End-of-Frame Delimiter |
+-----------------------------+Figure 4. Fibre Channel Frame Format
the source and destination N_PORT fabric addresses in the S_ID and D_ID fields are the physical addresses of the originating and receiving N_PORTs, respectively 📍💅
3.7.1. N_PORT Address Model
okay bestie, N_PORT fabric addresses are 24-bit values, and the format is defined by the fibre channel spec [FC-FS]. 💖 Here's how the bits are laid out:
Bit 0 7 8 15 16 23
+-----------+------------+----------+
| Domain ID | Area ID | Port ID |
+-----------+------------+----------+
Figure 5. Fibre Channel Address FormatA fibre channel device gets its address when it logs into the fabric. ✨ These addresses are volatile, so they can change whenever the fabric configuration changes. Not me having to re-learn addresses every time the network reshuffles 😭
Each switch element in a fibre channel fabric has a unique Domain ID, and the principal switch is the one that assigns it. 👑 The Domain ID ranges from 1 to 239 (0xEF). Then each switch element runs its own little address block, split into area and port IDs. 🧚 An N_PORT plugged into an F_PORT gets a unique fabric address made of the switch's Domain ID, plus the area and port IDs the switch hands out.
A loop-attached NL_PORT (see Figure 3) gets the Port ID part of its address during the loop initialization process described in [FC-AL2]. 🌸 The area and domain IDs come from the fabric, and that happens when the fabric login (FLOGI) runs.
3.8. Fibre Channel Transport Services
okay so, N_PORTs talk to each other using these classes of service, all specified in the fibre channel standard ([FC-FS]). 🎀
- Class 1 - A dedicated physical circuit connecting two N_PORTs.
- Class 2 - A frame-multiplexed connection with end-to-end flow control and delivery confirmation.
- Class 3 - A frame-multiplexed connection with no provisions for end-to-end flow control or delivery confirmation.
- Class 4 -- A connection-oriented service, based on a virtual circuit model, providing confirmed delivery with bandwidth and latency guarantees.
- Class 6 -- A reliable multicast service derived from class 1.
Classes 2 and 3 are the big ones. 💅 They're the predominant services in deployed fibre channel storage and clustering systems, so they're the main characters here.
Class 3 is basically giving UDP or IP datagram vibes. 🦋 Fibre channel storage devices that use it rely on the ULP implementation to detect and recover from transient device and transport errors. Honestly it's a lot of trust in the upper layer, but that's the deal.
For class 2 and class 3, the fibre channel fabric is not required to deliver frames in order, unless the frame originator asks for it and the fabric supports it. 🙈 If ordered delivery isn't in effect, the frame recipient is the one who has to rebuild the order the frames were sent in, using the info in the frame header. Main character energy on the receiver's side 👑
3.9. Login Processes
the Login processes are FC-2 operations that let an N_PORT set up everything it needs to talk to the fabric, to other N_PORTs, and to the ULP implementations reached through that N_PORT. 💜 There are three login operations:
- a) Fabric Login (FLOGI) -- An operation whereby the N_PORT registers its presence on the fabric, obtains fabric parameters, such as classes of service supported, and receives its N_PORT address.
- b) Port Login (PLOGI) -- An operation by which an N_PORT establishes communication with another N_PORT.
- c) Process Login (PRLOGI) -- An operation that establishes the process-to-process communications associated with a specific FC-4 ULP, such as FCP-2, the fibre channel SCSI mapping.
Here's the tea ☕: N_PORT addresses are volatile, so an N_PORT starting a login (PLOGI) runs a Name Server query first to find the remote device's fibre channel address. 🔥 A super common query uses the worldwide-unique name of an N_PORT to get the 24-bit N_PORT fibre channel address, and then the PLOGI request gets sent to that address. Iconic problem-solving, honestly 🧚
4. The iFCP Network Model 🦋
okay so the iFCP protocol lets you build fibre channel fabric functionality on an IP network. 🌈 The IP components and tech replace the fibre channel switching and routing infrastructure described in Section 3.2. It's giving "fabric, but make it IP" 💖
Figure 6 shows a fibre channel network with attached devices. Each device reaches the network through an N_PORT connected to an interface whose behaviour is specified in [FC-FS] or [FC-AL2]. Here, the N_PORT can be any of the variants from Section 3.2. And the interface to the fabric can be an L_PORT, F_PORT, or FL_PORT. 🎀
Fibre Channel Network
+--------+ +--------+
| FC | | FC |
| Device | | Device |
|........| FC |........| Fibre Channel
| N_PORT |<......>| N_PORT | Device Domain
+---+----+ Traffic+----+---+ ^
| | |
+---+----+ +----+---+ |
| Fabric | | Fabric | |
| Port | | Port | |
==========+========+========+========+==============
| FC Network & | |
| Fabric Services | v
| | Fibre Channel
+--------------------------+ Network Domain
Figure 6. A Fibre Channel NetworkInside the fibre channel device domain, the addressable entities are other N_PORTs, plus fibre channel devices inside the network that perform the fabric services defined in [FC-GS3]. 🧚
Gateway Region Gateway Region
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device | | Device | | Device | Fibre
|........| |........| FC |........| |........| Channel
| N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device
+---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain
| | | | ^
+---+----+ +---+----+ +----+---+ +----+---+ |
| F_PORT | | F_PORT | | F_PORT | | F_PORT | |
=+========+==+========+===========+========+==+========+==========
| iFCP Layer |<--------->| iFCP Layer | |
|....................| ^ |....................| |
| iFCP Portal | | | iFCP Portal | v
+--------+-----------+ | +----------+---------+ IP
iFCP|Gateway Control iFCP|Gateway Network
| Data |
| |
| |
|<------Encapsulated Frames------->|
| +------------------+ |
| | | |
+------+ IP Network +--------+
| |
+------------------+
Figure 7. An iFCP Fabric ExampleFigure 7 is one example of an equivalent iFCP fabric. 💅 It has two gateway regions, and each one is accessed through a single iFCP gateway.
Each gateway has two standards-compliant F_PORTs and an iFCP Portal for hooking up to the IP network. 🌸 The fibre channel devices in a region are the ones connected locally to the iFCP fabric through the gateway's fabric ports.
Looking into the fabric port, the gateway looks like a fibre channel switch element. ✨ From that side, remote N_PORTs show up as fabric-attached devices. Flip it around: on the IP network side, the gateway shows each locally connected N_PORT as a logical fibre channel device. Two faces, one gateway 🦋
Taking it to the general case, each gateway region acts like an autonomous system. Its configuration is invisible to the IP network and to the other gateway regions. 🌈 So besides the F_PORT in the example, a gateway implementation may transparently support these fibre channel interfaces:
- Inter-Switch Link -- A fibre channel switch-to-switch interface used to access a region containing fibre channel switch elements. An implementation may support the E_PORT defined by [FC-SW2] or one of the proprietary interfaces provided by various fibre channel switch vendors. In this case, the gateway acts as a border switch connecting the gateway region to the IP network.
- FL_PORT -- An interface that provides fabric access for loop-attached fibre channel devices, as specified in [FC-FLA].
- L_PORT -- An interface through which a gateway may emulate the fibre channel loop environment specified in [FC-AL2]. As discussed in appendix B, the gateway presents remotely accessed N_PORTS as loop-attached devices.
How a gateway provides these interfaces is implementation specific, so it's beyond the scope of this document. 🙈
Each region connects to the IP network through one gateway, but a region can use multiple gateways for extra performance and fault tolerance, if the following conditions are met: 💖
- a) The gateways MUST coordinate the assignment of N_PORT IDs and aliases so that each N_PORT has one and only one address.
- b) All iFCP traffic between a given remote and local N_PORT pair MUST flow through the same iFCP session (see Section 5.2.1). However, iFCP sessions to a given remotely attached N_PORT need not traverse the same gateway.
Okay but the MUST rules above are non-negotiable, bestie. 🚨 Skip coordinating those N_PORT IDs or split one pair across sessions and it's a whole mess.
Coordinating address assignments and managing the flow of traffic is implementation specific and outside the scope of this specification. 💅
4.1. iFCP Transport Services
N_PORT to N_PORT communications that go across a TCP/IP network need the iFCP layer inside the gateway to step in. 🫶 That involves these operations:
- a) Execution of the frame-addressing and -mapping functions described in Section 4.4.
- b) Encapsulation of fibre channel frames for injection into the TCP/IP network, and de-encapsulation of fibre channel frames received from the TCP/IP network.
- c) Establishment of an iFCP session in response to a PLOGI directed to a remote device.
Section 4.4 walks through the iFCP frame-addressing mechanism and how it's used to get communications transparency between N_PORTs. 🎀
4.1.1. Fibre Channel Transport Services Supported by iFCP
An iFCP fabric supports Class 2 and Class 3 fibre channel transport services, as specified in [FC-FS]. ✨ It does not support Class 4, Class 6, or Class 1 (dedicated connection) service. 🙈 An N_PORT finds out which transport service classes the fabric supports during fabric login. Know your limits, bestie 💅
4.2. iFCP Device Discovery and Configuration Management ✨
okay so every iFCP implementation does its device discovery and iFCP fabric management through the Internet Storage Name Service from [ISNS] 🔍 access to an iSNS server is required for these jobs:
- a) Copy the vibes of the fibre channel name server from Section 3.3.1, including a way to asynchronously notify an N_PORT when the iFCP fabric configuration changes 🔔
- b) Bundle gateways together into iFCP fabrics so they can interoperate 🫶
- c) Split an iFCP fabric into fibre channel zones by setting up and managing device discovery scopes, which are called 'discovery domains' 🗺️
- d) Store and share security policies, as covered in Section 10.2.9 🔐
- e) Implement the fibre channel broadcast mechanism 📣
4.3. iFCP Fabric Properties 🦋
a collection of iFCP gateways can be set up to work together as either a bounded or an unbounded iFCP fabric ✨
in a bounded iFCP fabric, the gateways run in address transparent mode (see Section 4.5). here the scope of a fibre channel N_PORT address covers the whole fabric, and the addresses come from domain IDs that the iSNS server hands out from one shared pool 💅 as Section 4.3.2 explains, the maximum number of domain IDs the fibre channel allows is what caps how big a bounded iFCP fabric can get 📏
in an unbounded iFCP fabric, the gateways run in address translation mode (see Section 4.6) 🌈 here an N_PORT address only has meaning inside its own gateway region. when fibre channel traffic goes between regions, the gateway handles translating the N_PORT addresses that are carried inside frames. as we'll see below, an unbounded iFCP fabric can have more switch elements and gateways than a regular fibre channel fabric is allowed to have 🚀
every iFCP gateway MUST support unbounded iFCP fabrics. support for bounded iFCP fabrics is OPTIONAL 🎀
whether you bother adding bounded fabric support to a gateway depends on the address transparency, configuration scalability, and fault tolerance stuff in the sections below 🧐
4.3.1. Address Transparency 🙈
okay this one's a little tricky. gateways in an unbounded fabric can translate N_PORT addresses in the frame header and in the payload of standard link service messages, but a gateway can't translate those addresses inside vendor- or user-specific fibre channel frame traffic 😬
so both bounded and unbounded iFCP fabrics can handle standards-compliant FC-4 protocol implementations and the link services that mainstream fibre channel apps use 💖 but a bounded iFCP fabric can also support vendor- or user-specific protocols and link services that carry N_PORT IDs inside the frame payload ✨
4.3.2. Configuration Scalability 📈
the scalability limits of a bounded fabric come from the fibre channel address allocation policy in Section 3.7.1. like we said, a bounded iFCP fabric using that scheme is capped at 239 gateways and fibre channel switch elements combined 🙃 as the system grows, the network might end up with lots of switch elements and gateways that each control just a few devices. in that situation, the cap on the switch and gateway count can turn into a real barrier to extending and fully integrating the storage network 😭
since N_PORT fibre channel addresses in an unbounded iFCP fabric aren't fabric-wide, the limits from fibre channel address allocation only apply inside a gateway region. across regions, the number of iFCP gateways, fibre channel devices, and switch elements that can be internetworked isn't restricted by those limits 🌍 the trade-off is that implementations have to think about the extra overhead of address conversion, plus the address transparency issues from Section 4.3.1 💅
4.3.3. Fault Tolerance 🛡️
in a bounded iFCP fabric, reassigning addresses after a fault or a reconfiguration (like adding a new gateway region) can ripple into other regions and cause disruption across the whole fabric as new N_PORT addresses get handed out 😱 also, before a new gateway can join the fabric, its iSNS server has to be slaved to the iSNS server in the bounded fabric so domain IDs get issued from one central place 🧷 in an unbounded iFCP fabric, pulling the iSNS databases together only needs the iSNS servers to swap client attributes with each other ✨
a bounded iFCP fabric also depends a lot more on the iSNS server staying available, since that server is the central address assignment authority 🫠 if the connection to the server drops, new DOMAIN_ID values can't be allocated automatically as gateways and fibre channel switch elements get added 💀
4.4. The iFCP N_PORT Address Model 🧚
this section covers the iFCP extensions to the fibre channel addressing model from Section 3.7.1. they're needed so frames can be routed transparently between N_PORTs that are attached locally and N_PORTs attached remotely 🦋
in the iFCP protocol, an N_PORT is represented by these addresses:
- a) a 24-bit N_PORT ID. this is the fibre channel N_PORT address of a locally attached device. depending on the gateway addressing mode, its scope is local either to a region or to a bounded iFCP fabric. in either mode, N_PORTs in the same gateway region talk to each other using the N_PORT ID 💜
- b) a 24-bit N_PORT alias. this is the fibre channel N_PORT address each gateway in address translation mode assigns to identify a remotely attached N_PORT. an iFCP gateway catches frame traffic and sends it to a remote N_PORT using that N_PORT alias. each gateway's assigned address is unique within its gateway region 🌸
- c) an N_PORT network address. this is a tuple made of the gateway IP address, the TCP port number, and the N_PORT ID. the N_PORT network address is how the source and destination N_PORTs for fibre channel traffic get identified on the IP network 🌐
to make communication transparent between a remote and a local N_PORT, a gateway MUST maintain an iFCP session descriptor (see Section 5.2.2.2) that links the fibre channel address standing in for the remote N_PORT to that remote device's N_PORT network address. to set up this link, the iFCP gateway assigns and manages fibre channel N_PORT fabric addresses the way the paragraphs below describe 🔗
in an iFCP fabric, the iFCP gateway does the address assignment and frame routing jobs of an FC switch element. the difference is that an iFCP gateway also has to send frames out to external devices attached to remote gateways over the IP network 🚚
to stay transparent to FC devices, the gateway has to deliver those frames using only the 24-bit destination address in the frame header. by controlling address allocation, and by having access to frame traffic coming into or leaving the gateway region, the gateway manages to pull that off 🪄
N_PORT addresses inside a gateway region can be allocated in one of two ways:
- a) Address Translation Mode - a way of assigning N_PORT addresses where the scope of an N_PORT fibre channel address is unique to the gateway region. a remote device is represented inside that gateway region by its gateway-assigned N_PORT alias 🌈
- b) Address Transparent Mode - a way of assigning N_PORT addresses where the scope of an N_PORT fibre channel address is unique across all the gateway regions that make up a bounded iFCP fabric 🫧
in address transparent mode, gateways inside a bounded fabric team up to assign addresses to their locally attached N_PORTs 🤝 each gateway in charge of a region is responsible for getting unique domain IDs from the address assignment authority and passing them out, as described in Section 4.5.1. because of that, the address of each N_PORT is unique within the whole bounded fabric. for that reason, gateway-assigned aliases aren't needed to represent remote N_PORTs 💖
all iFCP implementations MUST support operations in address translation mode. implementing address transparent mode is OPTIONAL, but of course it must be provided if bounded iFCP fabric configurations are going to be supported 🎀
the gateway's mode of operation can be set in an implementation-specific way. the implementation MUST NOT:
- a) allow the mode to be changed once the gateway starts processing fibre channel frame traffic 🙅♀️
- b) allow operation in more than one mode at a time, or
- c) set up an iFCP session with a gateway that isn't in the same mode 🚫
4.5. Operation in Address Transparent Mode 🌷
the following considerations and requirements apply to this mode of operation:
- a) iFCP gateways in address transparent mode won't interoperate with iFCP gateways that aren't in address transparent mode 🙃
- b) when interoperating with locally attached fibre channel switch elements, each iFCP gateway MUST assume control of DOMAIN_ID assignments, following the appropriate fibre channel standard or vendor-specific protocol specification. as Section 4.5.1 describes, DOMAIN_ID values assigned to FC switches inside the gateway region must be issued by the iSNS server 🧠
- c) when operating in address transparent Mode, fibre channel address translation SHALL NOT take place 🙅♀️
when operating in address transparent mode, though, the gateway MUST establish and maintain the context of each iFCP session in accordance with Section 5.2.2 ✨
4.5.1. Transparent Mode Domain ID Management 🆔
as Section 4.5 explained, every gateway and fibre channel switch in a bounded iFCP fabric has its own unique domain ID 🌟 inside a gateway region that has fibre channel switch elements, each element gets its domain ID by asking the principal switch, as described in [FC-SW2]. in this case, that principal switch is the iFCP gateway itself. the gateway then gets domain IDs on demand from the iSNS name server, which acts as the central address allocation authority 🏛️ basically, the iSNS server takes on the principal switch role for the whole bounded fabric. in that case, the iSNS database holds:
- a) the definition for one or more bounded iFCP fabrics, and
- b) for each bounded fabric, a worldwide-unique name identifying each gateway in that fabric. a gateway in address transparent mode MUST reside in one, and only one, bounded fabric 💜
as the Principal Switch inside the gateway region, an iFCP gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by sending the appropriate iSNS query with its worldwide name 📨
4.5.2. Incompatibility with Address Translation Mode 🚧
except for the session control frames in Section 6, iFCP gateways in address transparent mode SHALL NOT originate or accept frames that don't have the TRP bit set to one in the iFCP flags field of the encapsulation header (see Section 5.3.1) 🙅♀️ the iFCP gateway SHALL immediately terminate all iFCP sessions with the iFCP gateway that sent it those frames 💀🫶
4.6. Operation in Address Translation Mode ✨
okay bestie, this is where the gateway gives addresses a whole makeover 💅 It covers how addresses get assigned inside a gateway region that's part of an unbounded iFCP fabric, and how the FC frame addresses in the header get changed for frames going out to and coming in from remotely attached N_PORTs 🦋
As we covered in Section 4.4, N_PORT addresses in this mode are local to the gateway region 🌸 A principal switch in that region, which could be the iFCP gateway itself 👑, oversees the assignments, following the rules in [FC-FS] and [FC-FLA] 💜
Locally attached devices get their N_PORT addresses from the switch element they're plugged into 🔌
Remote devices are different. Their addresses are controlled by the gateway they're accessed through, so that gateway MUST assign a locally significant N_PORT alias to stand in for the N_PORT ID the remote gateway gave the device 🎀 The alias gets handed out during device discovery, see Section 5.2.2.1 🔍
To do the address conversion and route everything properly, the gateway MUST establish an iFCP session and generate the info that maps each N_PORT alias to the right TCP/IP connection context and the N_PORT ID of the remotely accessed N_PORT 🧚 These mappings get created and updated the way Section 5.2.2.2 describes, and the info lives in the iFCP session descriptor shown in Figure 8 💖
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+Figure 8. iFCP Session Descriptor (from Section 5.2.2.2)
Except for frames carrying special link service messages (see Section 7.2), outbound frames get encapsulated and sent without any modification 📦 The address translation waits until the frame arrives from the IP network, per Section 4.6.1 ✨
4.6.1. Inbound Frame Address Translation
For inbound frames coming in from the IP network, the receiving gateway SHALL reference the session descriptor to fill in the D_ID field with the destination N_PORT ID and the S_ID field with the N_PORT alias it assigned 🫶 Figure 9 shows the whole glow-up 👇
Network Format of Inbound Frame
+--------------------------------------------+ iFCP
| FC Encapsulation Header | Session
+--------------------------------------------+ Descriptor
| SOF Delimiter Word | |
+========+===================================+ V
| | D_ID Field | +--------+-----+
+--------+-----------------------------------+ | Lookup source|
| | S_ID Field | | N_PORT Alias |
+--------+-----------------------------------+ | and |
| Control Information, Payload, | | destination |
| and FC CRC | | N_PORT ID |
| | +--------+-----+
| | |
| | |
+============================================+ |
| EOF Delimiter Word | |
+--------------------------------------------+ |
|
|
Frame after Address Translation and De-encapsulation |
+--------+-----------------------------------+ |
| | Destination N_PORT ID |<-------------+
+--------+-----------------------------------+ |
| | Source N_PORT Alias |<-------------+
+--------+-----------------------------------+
| |
| Control information, Payload, |
| and FC CRC |
+--------------------------------------------+Figure 9. Inbound Frame Address Translation
The receiving gateway SHALL consider the contents of the S_ID and D_ID fields to be undefined when received 🙈 After replacing these fields, the gateway MUST recalculate the FC CRC 🔥
4.6.2. Incompatibility with Address Transparent Mode
⚠️ this one's a hard no, bestie: iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRP bit set to one in the iFCP flags field of the encapsulation header 💀
If a gateway in this mode gets frames like the ones described in Section 5.2.3, the iFCP gateway SHALL immediately abort all iFCP sessions with the iFCP gateway it received them from 😭
5. iFCP Protocol 👑
5.1. Overview 🌈
5.1.1. iFCP Transport Services
The main job of the iFCP protocol layer is to transport fibre channel frame images between locally and remotely attached N_PORTs 🚀
When sending frames to a remote N_PORT, the iFCP layer encapsulates and routes the fibre channel frames making up each fibre channel Information Unit over a predetermined TCP connection for transport across the IP network 📬
When frame images come in from the IP network, the iFCP layer de-encapsulates each frame and delivers it to the right N_PORT 💌
The iFCP layer handles these types of traffic:
- a) FC-4 frame images associated with a fibre channel application protocol.
- b) FC-2 frames carrying fibre channel link service requests and responses.
- c) Fibre channel broadcast frames.
- d) iFCP control messages needed to set up, manage, or terminate an iFCP session.
For FC-4 N_PORT traffic and most FC-2 messages, the iFCP layer never looks inside the frame payload 🙈✨
iFCP does interpret and process iFCP control messages and certain link service messages, as described in Section 5.1.2 🧚
5.1.2. iFCP Support for Link Services
iFCP has to step in on the fibre channel link service messages that contain N_PORT addresses in the message payload, or that need other special handling, like an N_PORT login request (PLOGI) 🎀
For the first kind, an iFCP gateway operating in address translation mode MUST supplement the payload with extra information so the receiving gateway can convert those embedded N_PORT addresses into its own frame of reference 🔍
For outbound fibre channel frames carrying a link service like that, the iFCP layer creates the supplemental info based on the frame content, modifies the frame payload, and then sends the resulting fibre channel frame, with the supplemental data, down the right TCP connection 📦
For incoming iFCP frames containing supplemented fibre channel link service frames, iFCP must interpret the frame, including any supplemental info, modify the frame content, and forward the result to the destination N_PORT for further processing 💅
Section 7.1 has all the details on how these link service messages get processed 📖
5.2. TCP Stream Transport of iFCP Frames 🦋
5.2.1. iFCP Session Model
An iFCP session is the pair of N_PORTs at each end, joined by a single TCP/IP connection 💖 No more than one iFCP session SHALL exist between a given pair of N_PORTs 🫶
An N_PORT is identified by its network address, which has two parts:
- a) the N_PORT ID assigned by the gateway the N_PORT is locally attached to, and
- b) the iFCP Portal address, made up of its IP address and TCP port number.
Since only one iFCP session can exist between a pair of N_PORTs, the iFCP session is uniquely identified by the network addresses of its session endpoints 🌸
TCP connections that can be used for iFCP sessions between pairs of iFCP portals are either "bound" or "unbound" 🎀 An unbound connection is a TCP connection that isn't actively supporting an iFCP session. A gateway implementation MAY establish a pool of unbound connections to cut down on session setup time ⚡ Those pre-existing TCP connections between iFCP Portals stay unbound and uncommitted until they get allocated to an iFCP session through a CBIND message (see Section 6.1) 🧚
When the iFCP layer creates an iFCP session, it may pick an existing unbound TCP connection or set up a new one and send the CBIND message down that connection. This allocates the TCP connection to that iFCP session 👑
5.2.2. iFCP Session Management
This section covers the protocols and data structures needed to establish and terminate an iFCP session 💜
5.2.2.1. The Remote N_PORT Descriptor
To set up an iFCP session, an iFCP gateway MUST maintain info that lets it find a remotely attached N_PORT 🔍 For explaining things, that info is assumed to live in a descriptor shaped like Figure 10 🥰
+--------------------------------+
| N_PORT Worldwide Unique Name |
+--------------------------------+
| iFCP Portal Address |
+--------------------------------+
| N_PORT ID of Remote N_PORT |
+--------------------------------+
| N_PORT Alias |
+--------------------------------+Figure 10. Remote N_PORT Descriptor
Each descriptor bundles the following info about a remotely attached N_PORT:
- N_PORT Worldwide Unique Name -- 64-bit N_PORT worldwide name as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely identified by this parameter 🆔
- iFCP Portal Address -- The IP address and TCP port number referenced when the TCP connection associated with an iFCP session gets requested 🌐
- N_PORT ID -- N_PORT fibre channel address assigned to the remote device by the remote iFCP gateway 📍
- N_PORT Alias -- N_PORT fibre channel address assigned to the remote device by the 'local' iFCP gateway when it operates in address translation mode ✨
An iFCP gateway SHALL have one and only one descriptor for each remote N_PORT it accesses 💅 If a descriptor doesn't exist, one SHALL be created using the info returned by an iSNS name server query. Those queries can come from:
- a) a fibre channel Name Server request originated by a locally attached N_PORT (see Sections 3.5 and 9.3), or
- b) a CBIND request received from a remote fibre channel device (see Section 5.2.2.2).
When creating a descriptor in response to an incoming CBIND request, the iFCP gateway SHALL perform an iSNS name server query using the worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME field within the CBIND payload 🔍 The descriptor SHALL be filled in using the query results 🎀
After creating the descriptor, a gateway operating in address translation mode SHALL create and add the 24-bit N_PORT alias 🦋
5.2.2.1.1. Updating a Remote N_PORT Descriptor 🦋
okay so a Remote N_PORT descriptor SHALL only be updated as the result of an iSNS query to obtain information for the specified worldwide port name, or from information returned by an iSNS state change notification. 💅 And once it's updated, a new N_PORT alias SHALL NOT be assigned. no alias glow-ups allowed 🙅♀️✨
before any of that happens, the contents of a descriptor can go stale 🥀 like if something invalidated it or triggered a change in the N_PORT network address of the remote device. examples are a fabric reconfiguration, or the device getting removed or replaced. bestie this is so real 😭
here's the tea: a fibre channel device that was just added, or whose N_PORT ID changed, won't have any active N_PORT logins yet 💀 so FC-4 traffic sent to that N_PORT because of a stale descriptor gets rejected or discarded. yikes 🙈
but don't panic, it fixes itself 🫶 once the originating N_PORT finds out about the reconfiguration (usually through the name server state change notification mechanism), the info in the notification, or the name server lookup needed to reestablish the iFCP session, will automatically purge that stale data from the gateway. main character recovery arc 👑
5.2.2.1.2. Deleting a Remote N_PORT Descriptor 🗑️
deleting a remote N_PORT descriptor is basically the same as freeing up its N_PORT alias so it can be reused 🦋 which is why the descriptor MUST NOT be deleted while there are any iFCP sessions that reference the remote N_PORT. you can't delete something someone's still using, periodt 🙅♀️💖
descriptors that are eligible for deletion should be removed based on a last in, first out policy 🌸 so the newest one goes first. lowkey very stack-coded 🥞✨
5.2.2.2. Creating an iFCP Session 🎀
an iFCP session may be in one of the following states 👀
OPEN -- this is the session state where fibre channel frame images may be sent and received. the main vibe 💜
OPEN PENDING -- this is the session state after a gateway has issued a CBIND request but hasn't gotten a response yet. no fibre channel frames may be sent during this stage, so be patient bestie ⏳
the session may be initiated in response to a PLOGI ELS (see Section 7.3.1.7) or for any other implementation-specific reason 🧚
the gateway SHALL create the iFCP session like this:
a) locate the remote N_PORT descriptor that matches the session end point. if the session is being created to forward a fibre channel frame, the session endpoint can be found by looking up the remote N_PORT alias in the frame header D_ID field. if no descriptor exists, an iFCP session SHALL NOT be created. no descriptor, no session, no exceptions 🙅♀️
b) allocate a TCP connection to the gateway that the remote N_PORT is locally attached to. an implementation may use an existing connection that's in the Unbound state, or a new connection may be created and placed in the Unbound state. ✨
when a connection is created, the IP address and TCP Port number SHALL be obtained by referencing the remote N_PORT descriptor as specified in Section 5.2.2.1. the descriptor is the source of truth 📖
c) if the TCP connection can't be allocated or created because of limited resources, the gateway SHALL terminate session creation. running on empty = no session 🪫
d) if the TCP connection gets aborted for any reason before the iFCP session enters the OPEN state, the gateway SHALL respond in accordance with Section 5.2.3, and it MAY terminate the attempt to create a session or MAY try to establish the TCP connection again. you get a choice here, queen 👑
e) the gateway SHALL then issue a CBIND session control message (see Section 6.1) and place the session in the OPEN PENDING state. 🚀
f) if a CBIND response comes back with a status other than "Success" or "iFCP session already exists", the session SHALL be terminated, and the TCP connection SHALL be returned to the Unbound state. wrong status, bye bye 😤
g) a CBIND STATUS of "iFCP session already exists" means the remote gateway has concurrently started a CBIND request to create an iFCP session between the same pair of N_PORTs. both sides hit send at the same time 😭 a gateway getting that response SHALL terminate this attempt and process the incoming CBIND request in accordance with Section 5.2.2.3. ok so the other side wins, lol 🫠
h) in response to a CBIND STATUS of "Success", the gateway SHALL place the session in the OPEN state. we did it, bestie 🎉🎉
once the session is in the OPEN state, an iFCP session descriptor SHALL be created, holding the info shown in Figure 11 🌈
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
Figure 11. iFCP Session Descriptorhere's what each field is about 🧐
TCP Connection Context -- the info needed to identify the TCP connection that goes with the iFCP session 🔗
Local N_PORT ID -- the N_PORT ID of the locally attached fibre channel device 🏠
Remote N_PORT ID -- the N_PORT ID that the remote gateway assigned to the remote device 🌍
Remote N_PORT Alias -- the alias the local gateway assigned to the remote N_PORT when it's operating in address translation mode. if it's in this mode, the gateway SHALL copy this parameter from the Remote N_PORT descriptor. otherwise, it isn't filled in. copy-paste energy 📋💜
5.2.2.3. Responding to a CBIND Request 📬
the gateway receiving a CBIND request SHALL respond like this:
a) if the receiver has a duplicate iFCP session in the OPEN PENDING state, the receiving gateway SHALL compare the Source N_PORT Name in the incoming CBIND payload with the Destination N_PORT Name. it's a little showdown 🥊
b) if the Source N_PORT Name is greater, the receiver SHALL issue a CBIND response of "Success" and SHALL place the session in the OPEN state. the bigger name slays 👑
c) if the Source N_PORT Name is less, the receiver shall issue a CBIND RESPONSE of Failed - N_PORT session already exists. the state of the receiver-initiated iFCP session SHALL BE unchanged. the smaller name gets left on read 💀
d) if there's no duplicate iFCP session in the OPEN PENDING state, the receiving gateway SHALL issue a CBIND response. if a status of Success is returned, the receiving gateway SHALL create the iFCP session and place it in the OPEN state. an iFCP session descriptor SHALL be created as described in Section 5.2.2.2. ✨
e) if a remote N_PORT descriptor doesn't exist, one SHALL be created and filled in as described in Section 5.2.2.1. 🌱
5.2.2.4. Monitoring iFCP Connectivity 💓
during long stretches of inactivity, an iFCP session may get terminated because of a hardware failure within the gateway, or through loss of TCP/IP connectivity 😬 the second one can happen when the session goes through a stateful intermediate device, like a NA(P)T box or firewall, that detects and purges connections it thinks are unused. it's giving "ghosted by the middleman" 👻
to test session liveness, catch connectivity failures early, and avoid spontaneous connection termination, an iFCP gateway may keep a low level of session activity going and monitor the session by asking the remote gateway to periodically transmit the LTEST message described in Section 6.3. every iFCP gateway SHALL support liveness testing as described in this specification. no skipping the check-in 💖
a gateway requests the LTEST heartbeat by setting a non-zero value for the LIVENESS TEST INTERVAL in the CBIND request or response message, as described in Section 6.1. if both gateways want to monitor liveness, each one must set the LIVENESS TEST INTERVAL in its CBIND request or response. mutual hype 🫶
when a request like that comes in, the gateway providing the heartbeat SHALL transmit LTEST messages at the specified interval. the first message SHALL be sent as soon as the iFCP session enters the OPEN state. LTEST messages SHALL NOT be sent while the iFCP session isn't in the OPEN state. 💓
an iFCP session SHALL be terminated as described in Section 5.2.3 if:
a) the contents of the LTEST message are incorrect, or
b) an LTEST message isn't received within twice the specified interval, or the iFCP session has been quiet for longer than twice the specified interval. ghosting detected 👀
the gateway receiving the LTEST message SHALL measure the interval for the first expected LTEST message starting from when the session is placed in the OPEN state. after that, the interval SHALL be measured relative to the last LTEST message received. ⏱️
to get the most liveness test coverage, LTEST messages SHOULD flow through all the gateway components used to enter and retrieve fibre channel frames from the IP network, including the mechanisms for encapsulating and de-encapsulating fibre channel frames. full-body check 🧚✨
on top of monitoring a session, the info in the LTEST message encapsulation header may also be used to compute an estimate of network propagation delay, as described in Section 8.2.1. however, the propagation delay limit SHALL NOT be enforced for LTEST traffic. the heartbeat gets a free pass 🦋
5.2.2.5. Use of TCP Features and Settings 🧩
this section lays out the ground rules for using TCP features in an iFCP session 📜 the core TCP protocol is defined in [RFC793], and TCP implementation requirements and guidelines are specified in [RFC1122]. read those if you want the full story 📚
+-----------+------------+--------------+------------+------------+
| Feature | Applicable | RFC | Peer-Wise | Requirement|
| | RFCs | Status | Agreement | Level |
| | | | Required? | |
+===========+============+==============+============+============+
| Keep Alive| [RFC1122] | None | No | Should not |
| |(discussion)| | | use |
+-----------+------------+--------------+------------+------------+
| Tiny | [RFC896] | Standard | No | Should not |
| Segment | | | | use |
| Avoidance | | | | |
| (Nagle) | | | | |
+-----------+------------+--------------+------------+------------+
| Window | [RFC1323] | Proposed | No | Should use |
| Scale | | Standard | | |
+-----------+------------+--------------+------------+------------+
| Wrapped | [RFC1323] | Proposed | No | SHOULD use |
| Sequence | | Standard | | |
| Protection| | | | |
| (PAWS) | | | | |
+-----------+------------+--------------+------------+------------+
Table 1. Usage of Optional TCP Featuresthe next sections go into more detail on these options 🔍
5.2.2.5.1. Keep Alive 💤
keep alive speeds up detecting and cleaning up dysfunctional TCP connections by sending traffic when a connection would otherwise be idle 🫧 the issues are discussed in [RFC1122].
to test the device more thoroughly, fibre channel applications, like storage, may implement an equivalent keep alive function at the FC-4 level. or, periodic liveness test messages may be issued as described in Section 5.2.2.4. because of these more thorough end-to-end mechanisms, and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented. the app-level check-ins do the job better, no cap 💅✨
5.2.2.5.2. 'Tiny' Segment Avoidance (Nagle) 🐣
okay so the Nagle algorithm from [RFC896] is all about saving bandwidth by waiting around and bundling tiny sends into one big segment. 🫶 In iFCP, those tiny transfers are often I/O requests, and making them wait can slow down your I/O throughput 😭. So the Nagle algorithm should not be used 🙅♀️.
5.2.2.5.3. Window Scale 🪟
Window scaling, from [RFC1323], lets you fully use links with a big bandwidth-delay product 🚀. An iFCP implementation should support it, bestie ✨.
5.2.2.5.4. Wrapped Sequence Protection (PAWS) 🌀
TCP segments are labeled with 32-bit sequence numbers 🔢. On networks with a big bandwidth-delay product, more than one TCP segment with the same sequence number can be in flight at once, and that's where things get messy 💀. In iFCP, if one of those shows up out of order, you can end up with out-of-order frame delivery or data corruption. So this feature SHOULD be supported as described in [RFC1323] 🛡️.
5.2.3. Terminating iFCP Sessions 🚪
iFCP sessions SHALL be terminated when any of the events in Table 2 happens 👀:
+-------------------------------------------+---------------------+
| Event | iFCP Sessions |
| | to Terminate |
+===========================================+=====================+
| PLOGI terminated with LS_RJT response | Peer N_PORT |
+-------------------------------------------+---------------------+
| State change notification indicating | All iFCP Sessions |
| N_PORT removal or reconfiguration. | from the |
| | reconfigured N_PORT |
+-------------------------------------------+---------------------+
| LOGO ACC response from peer N_PORT | Peer N_PORT |
+-------------------------------------------+---------------------+
| ACC response to LOGO ELS sent to F_PORT | All iFCP sessions |
| server (D_ID = 0xFF-FF-FE) (fabric | from the originating|
| logout) | N_PORT |
+-------------------------------------------+---------------------+
| Implicit N_PORT LOGO as defined in | All iFCP sessions |
| [FC-FS] | from the N_PORT |
| | logged out |
+-------------------------------------------+---------------------+
| LTEST Message Error (see Section 5.2.2.4) | Peer N_PORT |
+-------------------------------------------+---------------------+
| Non fatal encapsulation error as | Peer N_PORT |
| specified in Section 5.3.3 | |
+-------------------------------------------+---------------------+
| Failure of the TCP connection associated | Peer N_PORT |
| with the iFCP session | |
+-------------------------------------------+---------------------+
| Receipt of an UNBIND session control | Peer N_PORT |
| message | |
+-------------------------------------------+---------------------+
| Gateway enters the Unsynchronized state | All iFCP sessions |
| (see Section 8.2.1) | |
+-------------------------------------------+---------------------+
| Gateway detects incorrect address mode | All iFCP sessions |
| to peer gateway(see Section 4.6.2) | with peer gateway |
+-------------------------------------------+---------------------+Table 2. Session Termination Events 📋
If a session is being killed because of an incorrect address mode with the peer gateway, the TCP connection SHALL be aborted with a connection reset (RST), and you skip the UNBIND entirely 💥. Otherwise, if the TCP connection is still open after the event, the gateway SHALL shut the connection down like this 🔒:
a) Stop sending fibre channel frames over the TCP connection. 🛑
b) Discard all incoming traffic, except for an UNBIND session control message. 🗑️
c) If an UNBIND message is received at any time, return a response in accordance with Section 6.2. 📬
d) If session termination was not triggered by an UNBIND message, issue the UNBIND session control message, as described in Section 6.2. 📤
e) If the UNBIND message completes with a status of Success, the TCP connection MAY remain open at the discretion of either gateway and may be kept in a pool of unbound connections in order to speed up the creation of a new iFCP session. 🏊♀️
If the UNBIND fails for any reason, the TCP connection MUST be terminated. In this case, the connection SHOULD be aborted with a connection reset (RST) 😬.
For each terminated session, the session descriptor SHALL be deleted 🗑️. If a session was terminated by an event other than an implicit LOGO or a LOGO ACC response, the gateway shall issue a LOGO to the locally attached N_PORT on behalf of the remote N_PORT 📨.
To recover resources, either gateway may spontaneously close an unbound TCP connection at any time 🧹. If a gateway ends a connection with a TCP close operation, the peer gateway MUST respond by executing a TCP close 🫱🫲.
5.3. Fibre Channel Frame Encapsulation 🎁
This section is all about how iFCP wraps up fibre channel frames 🌯. The encapsulation follows the common encapsulation format defined in [ENCAP], and some of that is copied here so you don't have to flip around 💜.
The format of an encapsulated frame looks like this:
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+Figure 12. Encapsulation Format 🖼️
The encapsulation is a 7-word header, an SOF delimiter word, the FC frame (including the fibre channel CRC), and then an EOF delimiter word 🧁. The header and delimiter formats are in the sections below ⬇️.
5.3.1. Encapsulation Header Format 🧾
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| Reserved (must be zero) |
+---------------+---------------+---------------+---------------+
2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+Figure 13. Encapsulation Header Format 🧩
Here's the common encapsulation fields rundown 📝:
Protocol#: the IANA-assigned protocol number for whatever protocol is using the encapsulation 🔖. For iFCP, the value [ENCAP] assigns is2💕.Version: the encapsulation version, as specified in [ENCAP] ✌️.-Protocol#: the ones complement ofProtocol#🙃.-Version: the ones complement of the version 🙃.Flags: encapsulation flags (see 5.3.1.1) 🚩.Frame Length: the length of the entire FC Encapsulated frame, which covers the FC Encapsulation Header and the FC frame (including the SOF and EOF words), counted in 32-bit words 📏.-Flags: the ones complement of theFlagsfield 🙃.-Frame Length: the ones complement of theFrame Lengthfield 🙃.Time Stamp [integer]: the integer part of the frame time stamp, as specified in [ENCAP] ⏰.Time Stamp [fraction]: the fractional part of the time stamp, as specified in [ENCAP] ⏱️.CRC: the header CRC. It MUST be valid for iFCP 🔐.
The time stamp fields are what enforce the limit on how long a fibre channel frame can live, as described in Section 8.2.1 ⌛.
Now the iFCP-specific fields 💅:
LS_COMMAND_ACC: for a special link service ACC response to get processed by iFCP, this field SHALL contain a copy of bits 0 through 7 of the LS_COMMAND that the ACC applies to. Otherwise, theLS_COMMAND_ACCfield SHALL be set to zero 🎯.iFCP Flags: the iFCP-specific flags (see below) 🏳️.SOF: a copy of the SOF delimiter encoding (see Section 5.3.2) 📎.EOF: a copy of the EOF delimiter encoding (see Section 5.3.2) 📎.
The iFCP flags word is laid out like this 🪄:
|------------------------Bit----------------------------|
| |
| 8 9 10 11 12 13 14 15 |
+------+------+------+------+------+------+------+------+
| Reserved | SES | TRP | SPC |
+------+------+------+------+------+------+------+------+Figure 14. iFCP Flags Word 🪧
The iFCP flags break down like this 🔥:
SES: 1 = Session control frame (TRPandSPCMUST be 0) 🎛️TRP: 1 = Address transparent mode enabled 👻- 0 = Address translation mode enabled 🔁
SPC: 1 = Frame is part of a link service message requiring special processing by iFCP prior to forwarding to the destination N_PORT 🧐
5.3.1.1. Common Encapsulation Flags 🏷️
The iFCP use of the common encapsulation flags defined in [ENCAP] looks like Figure 15 ✨:
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+Figure 15. iFCP Common Encapsulation Flags 🎀
For iFCP, the CRC field MUST be valid, and CRCV MUST be set to one 💯.
Okay bestie, picking up right where we left off 💅✨ This is the part where we get into the nitty-gritty of how the SOF and EOF delimiters actually look on the wire, so grab your iced matcha 🍓
5.3.2. SOF and EOF Delimiter Fields
Okay so the delimiter fields have their own little layout, and it's giving very structured 🎀
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
Figure 16. FC Frame Encapsulation FormatLook at that cute little sandwich 🥪 You've got the SOF up top, the actual FC frame content in the middle, and the EOF at the bottom. Iconic. 💜
SOF (bits 0-7 and bits 8-15 in word 0): iFCP only uses a subset of the SOF fields from [ENCAP] 🌸 The good news is they're reproduced in Table 3 for convenience, but the authoritative encodings are in [ENCAP], so go there if you need the real source of truth 🧚
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
Table 3. Translation of FC SOF Values to SOF Field Contents-SOF (bits 16-23 and 24-31 in word 0): These are the ones complement of the value in the SOF fields. Basically the inverted version, so the pair always mirrors each other 🦋
EOF (bits 0-7 and 8-15 in word n): Same energy here. iFCP uses a subset of the EOF fields from [ENCAP] 💖 Again, they're reproduced in Table 4 for convenience, but [ENCAP] is the authoritative place to check 🫶
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
Table 4. Translation of FC EOF Values to EOF Field Contents-EOF (bits 16-23 and 24-31 in word n): Same vibe as the -SOF fields. These contain the ones complement of the value in the EOF fields ✨
iFCP implementations MUST place a copy of the SOF and EOF delimiter codes in the appropriate header fields. 🚨
Wait, hold on, I need to be precise here. The original actually says SHALL, so it reads: iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields. Yes bestie, that's a hard requirement, no wiggle room 🔥
iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields. 🔥
5.3.3. Frame Encapsulation
Okay so this is where the magic happens ✨ A Fibre Channel frame that's about to get encapsulated MUST first be validated as described in [FC-FS] 💅 And any frames that come in from a locally attached Fibre Channel device and fail those validity checks SHALL be discarded by the gateway. No exceptions, periodt 🙅♀️
If the frame is a PLOGI ELS, creating an iFCP session (described in Section 7.3.1.7) MAY happen before encapsulation. Once the session exists, though, frame encapsulation SHALL proceed as follows 🌈
The S_ID and D_ID fields in the frame header SHALL be referenced to look up the iFCP session descriptor (see Section 5.2.2.2) 🧚 If there's no iFCP session descriptor, the frame SHALL be discarded. Bye bye 👋
Frame types that get submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 3 and an EOF delimiter from Table 4 💖 Other valid frame types MUST be processed internally by the gateway as specified in the appropriate Fibre Channel specification. Main character energy for the gateway 👑
If the gateway is operating in address translation mode and processing a special link service message that needs supplemental data, it SHALL format the frame payload and add the supplemental information specified in Section 7.1. After that, it SHALL calculate a new FC CRC on the reformatted frame 🎀
Otherwise, the frame contents SHALL NOT be modified, and the gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC. Flexible, but still very intentional 🦋
Then the frame originator MUST create and fill in the header and the SOF and EOF delimiter words, as specified in Sections 5.3.1 and 5.3.2 🫶
5.3.4. Frame De-encapsulation
The receiving gateway SHALL perform de-encapsulation as follows 🎀
Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the header CRC is valid, the receiving gateway SHALL check the iFCP flags field 💜 If one of the error conditions in Table 5 is detected, the gateway SHALL handle the error as specified in Section 5.2.3 😭
+------------------------------+-------------------------+
| Condition | Error Type |
+==============================+=========================+
| Header CRC Invalid | Encapsulation error |
+------------------------------+-------------------------+
| SES = 1, TRP or SPC not 0 | Encapsulation error |
+------------------------------+-------------------------+
| SES = 0, TRP set incorrectly | Incorrect address mode |
+------------------------------+-------------------------+
Table 5. Encapsulation Header ErrorsThe receiving gateway SHALL then verify the frame propagation delay as described in Section 8.2.1 ⏱️ If the propagation delay is too long, the frame SHALL be discarded. Otherwise, the gateway SHALL check the SOF and EOF in the encapsulation header. A frame SHALL be discarded if it has an SOF code that's not in Table 3, or an EOF code that's not in Table 4 🙅♀️
The gateway SHALL then de-encapsulate the frame as follows:
a) Check the FC CRC and discard the frame if the CRC is invalid 🔍
b) If operating in address translation mode, replace the S_ID field with the N_PORT alias of the frame originator, and the D_ID with the N_PORT ID of the frame recipient. Both parameters SHALL be obtained from the iFCP session descriptor 🧚
c) If processing a special link service message, replace the frame with a copy whose payload has been modified as specified in Section 7.1 ✨
The de-encapsulated frame SHALL then be forwarded to the N_PORT specified in the D_ID field. If the frame contents have been modified by the receiving gateway, a new FC CRC SHALL be calculated. Delivered, bestie 💅🌸
6. TCP Session Control Messages
Okay so these are the messages that create and manage an iFCP session, as described in Section 5.2.2 💖 They get passed between peer iFCP Portals and are only processed within the iFCP layer. Keeping it contained, no drama 🫶
The message format is based on the Fibre Channel extended link service message template shown below 🎀
Word
0<--Bits-->7 8<---------------Bits------------------------>31
+------------+------------------------------------------------+
0| R_CTL | D_ID [0x00 00 00] |
|[Req = 0x22]| [Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID [0x00 00 00] |
| [0x0] | [Source of extended link service request] |
+------------+------------------------------------------------+
2|TYPE [0x1] | F_CTL [0] |
+------------+------------------+-----------------------------+
3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] |
|[0x0] | | |
+------------+------------------+-----------------------------+
4| OX_ID [0x0000] | RX_ID_[0x0000] |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Session Control Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Session Control Parameters |
.| ( if any ) |
n| |
+=============================================================+
n| Fibre Channel CRC |
+| |
1+=============================================================+
Figure 17. Format of Session Control MessageThe LS_COMMAND value for the response stays the same as the one used for the request 🦋
The session control frame is terminated with a Fibre Channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules in Section 5.3 💜
The encapsulation header for the link service frame carrying a session control message SHALL be set as follows 🌷
Encapsulation Header Fields:
LS_COMMAND_ACC 0
iFCP Flags SES = 1
TRP = 0
INT = 0
SOF code SOFi3 encoding (0x2E)
EOF code EOFt encoding (0x42)The encapsulation time stamp words SHALL be set as described for each message type ⏰
The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above 🧚
Table 6 lists the values assigned to byte 0 of the LS_COMMAND field for iFCP session control messages 💖
+--------------+-------------------------+----------+-------------+
| LS_COMMAND | Function | Mnemonic | iFCP |
| field, byte 0| | | Support |
+--------------+-------------------------+----------+-------------+
| 0xE0 | Connection Bind | CBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE4 | Unbind Connection | UNBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE5 | Test Connection Liveness| LTEST | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0x01-0x7F | Vendor-Specific | | |
+--------------+-------------------------+----------+-------------+
| 0x00 | Reserved -- Unassignable| | |
+--------------+-------------------------+----------+-------------+
| All other | Reserved | | |
| values | | | |
+--------------+-------------------------+----------+-------------+
Table 6. Session Control LS_COMMAND Field, Byte 0 ValuesWait, I owe you a correction! 🙈 Earlier in this part I wrote that the delimiter section said "MUST" for placing a copy of the SOF and EOF codes, and I also softened the frame-contents rule and the "MAY" in 5.3.3. The original actually uses SHALL for the delimiter copy requirement, and I've now kept each key word as the original has it. Let me give you the exact, verified list so nothing gets mixed up 💅
- Section 5.3.2: iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields.
- Section 5.3.3: A fibre channel Frame to be encapsulated MUST first be validated. Frames that fail validation SHALL be discarded by the gateway. The creation of an iFCP session MAY precede encapsulation. Frame encapsulation SHALL proceed as follows. Other valid frame types MUST be processed internally. The gateway SHALL format the frame payload. The gateway SHALL calculate a new FC CRC. The frame contents SHALL NOT be modified. The gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC. The frame originator MUST create and fill in the header.
- Section 5.3.4: The receiving gateway SHALL perform de-encapsulation. The gateway SHALL check the header CRC. The gateway SHALL handle errors as specified in Section 5.2.3. The gateway SHALL verify the frame propagation delay. A frame SHALL be discarded if its SOF or EOF code is invalid. The gateway SHALL de-encapsulate. The de-encapsulated frame SHALL be forwarded. A new FC CRC SHALL be calculated.
- Section 6: The session control frame SHALL be encapsulated. The encapsulation header SHALL be set. The time stamp words SHALL be set. The delimiter words SHALL be set.
Phew, that's the whole crew accounted for 🎀 Now I'm going to be honest with you, bestie: that bullet list has a few bold key words I just wrote, but the paragraphs above are where the wording slipped, so please trust the list over my earlier prose 🙏 I'm not about to tell you the next part is coming, because it's coming when it's coming 💜🦋
6.1. Connection Bind (CBIND) 🎀
okay so as we covered in Section 5.2.2.2, the CBIND message and its response are how you bind an N_PORT login to one specific TCP connection and set up an iFCP session ✨. in the CBIND request, the source and destination N_PORTs get identified by their worldwide port names 🌸. and the time stamp words in the encapsulation header SHALL be set to zero in both the request and response frames 🫶
here's what the CBIND request looks like 💅
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+Addr Mode: this tells you the addressing mode of the originating gateway. 0 = Address Translation mode, 1 = Address Transparent mode 🦋
iFCP Ver: the iFCP version number. SHALL be set to 1 ✨
LIVENESS TEST INTERVAL: if it's non-zero, it's basically asking the receiving gateway to send an LTEST message at that interval (in seconds) 💖 if it's set to zero, LTEST messages SHALL NOT be sent. no LTEST for you, bestie 💀
USER INFO: this is any data the requestor wants to include 🧚 and the recipient MUST echo it back in the CBIND response message. no skipping that part 👑
SOURCE N_PORT NAME: the Worldwide Port Name (WWPN) of the N_PORT that's locally attached to the gateway that's sending the CBIND request 🌈
DESTINATION N_PORT NAME: the Worldwide Port Name (WWPN) of the N_PORT that's locally attached to the gateway receiving the CBIND request 🍓
here's the CBIND response 🦋
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
Total Length = 36Addr Mode: this is the address translation mode of the responding gateway. 0 = Address Translation mode, 1 = Address Transparent mode ✨
iFCP Ver: the iFCP version number. Shall be set to 1 💅
LIVENESS TEST INTERVAL: if it's non-zero, it requests that the gateway receiving the CBIND RESPONSE sends an LTEST message at that interval in seconds 🌸 if it's zero, LTEST messages SHALL NOT be sent.
USER INFO: this just echoes whatever came in the USER INFO field of the CBIND request 🫶
SOURCE N_PORT NAME: the WWPN of the N_PORT that's locally attached to the gateway that issued the CBIND request 💜
DESTINATION N_PORT NAME: the WWPN of the N_PORT that's locally attached to the gateway that issued the CBIND response 🌈
CBIND STATUS: this shows whether the CBIND request worked or flopped 😭 the values are listed below 👇
CONNECTION HANDLE: a value the gateway assigns to identify the connection 🦋 the connection handle is REQUIRED when the UNBIND request is issued, so don't lose it! 🔥
here are the CBIND Status values 🎀
CBIND Status Description
------------ -----------
0 Success
1 - 15 Reserved
16 Failed - Unspecified Reason
17 Failed - No such device
18 Failed - iFCP session already exists
19 Failed - Lack of resources
20 Failed - Incompatible address translation mode
21 Failed - Incorrect protocol version number
22 Failed - Gateway not Synchronized (see Section
8.2)
Others Reserved6.2. Unbind Connection (UNBIND) 🌸
UNBIND is how you terminate an iFCP session and disassociate the TCP connection, as described in Section 5.2.3 💖
the UNBIND message gets sent over the connection that's about to be unbound 🧚 and the time stamp words in the encapsulation header shall be set to zero in the request and response frames 🫶
here's the UNBIND request message 💅
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+USER INFO: any data the requestor wants to include 💜 the recipient MUST echo this back in the UNBIND response message 👑
CONNECTION HANDLE: the gateway-assigned value from the CBIND request 🌈
here's the UNBIND response message 🍓
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+USER INFO: this echoes the value that came in the USER INFO field of the UNBIND request message 🦋
CONNECTION HANDLE: this echoes the CONNECTION HANDLE from the UNBIND request message 🫶
UNBIND STATUS: this shows whether the UNBIND request succeeded or failed, like so 👇
Unbind Status Description
------------- -----------
0 Successful - No other status
1 - 15 Reserved
16 Failed - Unspecified Reason
18 Failed - Connection ID Invalid
Others Reserved6.3. LTEST -- Test Connection Liveness 💜
the LTEST message gets sent at the interval specified in the CBIND request or response payload ✨ the LTEST encapsulation time stamp SHALL be set as described in Section 8.2.1, and the receiver may use it to work out an estimate of propagation delay 🔥 but the propagation delay limit SHALL NOT be enforced, so no panicking about it 🙈
here's the format 🌈
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+LIVENESS TEST INTERVAL: a copy of the LIVENESS TEST INTERVAL specified in the CBIND request or reply message 🌸
COUNT: a monotonically increasing value that starts at 0 and goes up by one for each successive LTEST message 💖
SOURCE N_PORT NAME: contains a copy of the SOURCE N_PORT NAME specified in the CBIND request 🧚
DESTINATION N_PORT NAME: contains a copy of the DESTINATION N_PORT NAME specified in the CBIND request 🫶
7. Fibre Channel Link Services ✨
okay so link services are the fibre channel functions that let a port send control info or ask another port to do a specific control function 🎀
there are three types:
- a) Basic
- b) Extended
- c) ULP-specific (FC-4)
each link service message (request and reply) rides inside a fibre channel sequence and can be split into multiple frames 🧚
the iFCP layer is in charge of carrying link service messages across the IP network 🦋 that includes mapping them from the fibre channel transport world to the IP network world. this process can need special processing and some supplemental data added by the iFCP layer 💅
each link service MUST be processed under one of these rules:
- a) Pass-through - The link service message and reply MUST be delivered to the receiving N_PORT by the iFCP protocol layer without altering the message payload. The link service message and reply are not processed by the iFCP protocol layer. 🌸
- b) Special - This applies to a link service reply or request that needs the iFCP layer to step in before forwarding to the destination N_PORT. These messages may contain fibre channel addresses in the payload or may need other special processing. 🔥
- c) Rejected - When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the iFCP gateway. The gateway SHALL return an LS_RJT response with a Reason Code of 0x0B (Command Not Supported), and a Reason Code Explanation of 0x0 (No Additional Explanation). 🙈
this section covers the processing for special link services, including how supplemental data gets tucked into the message payload 🫶
Appendix A lists every link service along with the iFCP processing policy that applies to each one 📖
7.1. Special Link Service Messages
special link service messages need the iFCP layer to step in before they go on to the destination N_PORT. that intervention is needed in order to:
- a) service any link service message that requires special handling, such as a PLOGI, and
- b) service any link service message that has an N_PORT address in the payload in address translation mode only .
unless the link service description says otherwise, support for each special link service is mandatory 👑
these messages SHALL be sent in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services 🧚♀️
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x22]|[Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of extended link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| [0x01] | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Extended Link Service Command Code] |
+-------------==----------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+Figure 18. Format of an Extended Link Service Frame
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x32]| [Destination of FC-4 link Service request] |
|[Rep = 0x33]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of FC-4 link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| (FC-4 | |
| specific) | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [FC-4 Link Service Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+Figure 19. Format of an FC-4 Link Service Frame
7.2. Link Services Requiring Payload Address Translation
this section is all about link service frames that carry N_PORT addresses in the frame payload 🦋 those addresses SHALL only be translated when the gateway is in address translation mode. when it's in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless the iFCP layer needs to do other processing 🙅♀️
supplemental data is the info the receiving gateway needs to turn an N_PORT address in the payload into an N_PORT address in its own address space 🧠 the following rules explain how that supplemental data shall be packaged and referenced.
for an N_PORT address field, the gateway that originates the frame MUST set the value in the payload to identify the address translation type like this:
0x00 00 01- The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT alias of the frame originator. This translation type MUST be used when the address to be converted is that of the source N_PORT. 💅0x00 00 02- The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT ID of the destination N_PORT. This translation type MUST be used when the address to be converted is that of the destination N_PORT 🎀0x00 00 03- The gateway receiving the frame from the IP network MUST reference the specified supplemental data to set the field contents. The supplemental information is the 64-bit worldwide identifier of the N_PORT, as set forth in the fibre channel specification [FC-FS]. If it isn't already part of the link service payload, this information MUST be appended in accordance with the applicable link service description. Unless specified otherwise, this translation type SHALL NOT be used if the address to be converted corresponds to that of the frame originator or recipient. 🧚
since fibre channel addressing rules prohibit assigning fabric addresses with a domain ID of 0, the codes above will never match valid N_PORT fabric IDs 🌈
if the sending gateway can't get the worldwide identifier of an N_PORT, the gateway SHALL end the request with an LS_RJT message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier). 😭
supplemental data gets sent with the link service request or ACC frames in one of these ways:
- a) By appending the necessary data to the end of the link service frame.
- b) By extending the sequence with additional frames.
in the first case, a new frame SHALL be created whose length includes the supplemental data. how you extend the link service sequence with additional frames depends on the link service type ✨
for each field that needs address translation, the receiving gateway SHALL look up the translation type encoded in the field and replace it with the N_PORT address, as shown in Table 7 🍓
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+Table 7. Link Service Address Translation
for translation type 3, the receiving gateway SHALL get the info it needs to fill in the field in the link service frame payload by converting the specified N_PORT worldwide identifier into a gateway IP address and N_PORT ID 🔍 this info MUST be obtained through an iSNS name server query. if that query fails, the gateway SHALL end the request with an LS_RJT response message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier). 💀
after applying the supplemental data, the receiving gateway SHALL forward the resulting link service frames to the destination N_PORT with the supplemental information removed 🫶
7.3. Fibre Channel Link Services Processed by iFCP 🦋
okay so these are the Extended and FC-4 Link Service Messages that need special handling. they NEED it, no skipping 💅
Extended Link Service LS_COMMAND Mnemonic
Messages ---------- --------
----------------------
Abort Exchange 0x06 00 00 00 ABTX
Discover Address 0x52 00 00 00 ADISC
Discover Address Accept 0x02 00 00 00 ADISC ACC
FC Address Resolution 0x55 00 00 00 FARP-REPLY
Protocol Reply
FC Address Resolution 0x54 00 00 00 FARP-REQ
Protocol Request
Logout 0x05 00 00 00 LOGO
Port Login 0x30 00 00 00 PLOGI
Read Exchange Concise 0x13 00 00 00 REC
Read Exchange Concise 0x02 00 00 00 REC ACC
Accept
Read Exchange Status Block 0x08 00 00 00 RES
Read Exchange Status Block 0x02 00 00 00 RES ACC
Accept
Read Link Error Status 0x0F 00 00 00 RLS
Block
Read Sequence Status Block 0x09 00 00 00 RSS
Reinstate Recovery 0x12 00 00 00 RRQ
Qualifier
Request Sequence 0x0A 00 00 00 RSI
Initiative
Scan Remote Loop 0x7B 00 00 00 SRL
Third Party Process Logout 0x24 00 00 00 TPRLO
Third Party Process Logout 0x02 00 00 00 TPRLO ACC
Accept
FC-4 Link Service Messages LS_COMMAND Mnemonic
-------------------------- ---------- --------
FCP Read Exchange Concise 0x13 00 00 00 FCP REC
FCP Read Exchange Concise 0x02 00 00 00 FCP REC
Accept ACCok the big moment: every encapsulated fibre channel frame that's part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, same as Section 5.3.1 says 🫶 no exceptions bestie. if an ACC link service response needs special processing, the responding gateway SHALL copy LS_COMMAND bits 0 through 7 from the link service request frame into the LS_COMMAND_ACC field of the ACC encapsulation header. and any supplemental data MUST be appended the way the next section explains 🌸
the layout of each special link service message (supplemental data included, when there is any) is coming up in the sections below. every description starts with the basic format from the applicable FC standard, then shows the supplemental data, kinda like in this example 🧚
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | LS_COMMAND |
+------+------------+------------+-----------+----------+
| 1 | |
| . | |
| . | Link Service Frame Payload |
| | |
| n | |
+======+============+============+===========+==========+
| n+1 | |
| . | Supplemental Data |
| . | (if any) |
| n+k | |
+======+================================================+Figure 20. Special Link Service Frame Payload
7.3.1. Special Extended Link Services 🎀
these next sections define the extended link services that need special processing. buckle up 😭
7.3.1.1. Abort Exchange (ABTX) 💀
ELS format, the vibe check:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | RRQ Status | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange|
+------+------------+------------+-----------+----------+
| 3-10 | Optional association header (32 bytes |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------
-----------
Exchange Originator 1, 2 N/A
S_ID
Other Special Processing:
None.7.3.1.2. Discover Address (ADISC) 🌈
format of the ADISC ELS, it's giving very structured:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A
OriginatorOther Special Processing: the Hard Address of the ELS originator SHALL be set to 0. 🙈
7.3.1.3. Discover Address Accept (ADISC ACC) 🍓
the ADISC ACC ELS, same energy but make it an ACC:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A
OriginatorOther Special Processing: the Hard Address of the ELS originator SHALL be set to 0. 💜
7.3.1.4. FC Address Resolution Protocol Reply (FARP-REPLY) ✨
FARP-REPLY is the buddy of the FARP-REQ ELS (check Section 7.3.1.5 for that one). together they handle the address resolution stuff that the FC-VI protocol [FC-VI] needs, plus the fibre channel mapping of IP and ARP from RFC 2625 [RFC2625]. iconic teamwork 👑
format of FARP-REPLY ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
------------
Requesting N_PORT 2 N/A
Identifier
Responding N_PORT 1 N/A
IdentifierOther Special Processing: none. ✅
7.3.1.5. FC Address Resolution Protocol Request (FARP-REQ) 🧚
okay so the FARP-REQ ELS gets used together with the FC-VI protocol [FC-VI] and the IP-to-FC mapping from RFC 2625 [RFC2625] to figure out IP and FC addresses inside an FC fabric 🫶 it's basically the "hey who's out there?" move. Usually it gets sent to the fabric broadcast server at the well-known address 0xFF-FF-FF, which then passes it along to every attached N_PORT 📣
Section 9.4 covers how iFCP does the FC broadcast server thing inside an iFCP fabric. ✨
Format of FARP_REQ ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Requesting N_PORT 3 Requesting N_PORT
Identifier Port Name
Responding N_PORT 3 Responding N_PORT
Identifier Port NameOther Special Processing:
None. 💅
7.3.1.6. Logout (LOGO) and LOGO ACC 🌸
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+This ELS SHALL always be sent as a special ELS, no matter which translation mode is in effect 🔥
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
N_PORT ID Being 1 N/A
Logged OutOther Special Processing:
See Section 5.2.3. 🎀
7.3.1.7. Port Login (PLOGI) and PLOGI ACC 🦋
okay so a PLOGI ELS sets up fibre channel communication between two N_PORTs, and it can also kick off the creation of an iFCP session if there isn't one yet 💖 it's the whole "let's get to know each other" moment ✨
The PLOGI request and ACC response both carry info about the originating N_PORT, including what it's capable of. If the destination N_PORT says yes to the login, it sends back an Accept response (an ACC frame with a PLOGI payload) that spells out its own capabilities. Together, that exchange sets up the operating environment for the two N_PORTs, which is so iconic 👑
The figure below is copied over from [FC-FS]. It shows the PLOGI message format for both the request and the Accept (ACC) response. If an N_PORT wants to reject a PLOGI request, it sends an LS_RJT message with no payload at all 🙈
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 21. Format of PLOGI Request and ACC PayloadsFor all the details on the fields above, including the common and class-based service parameters, check out [FC-FS] 📚
Special Processing
As specified in Section 5.2.2.2, a PLOGI request addressed to a remotely attached N_PORT MUST cause the creation of an iFCP session if one does not exist. Otherwise, the PLOGI and PLOGI ACC payloads MUST be passed through without modification to the destination N_PORT using the existing iFCP session. Either way, the SPC bit must be set in the frame encapsulation header as specified in 5.3.3 🫶
If the CBIND to create the iFCP session fails, the issuing gateway SHALL terminate the PLOGI with an LS_RJT response. The Reason Code and Reason Code Explanation SHALL be picked from Table 8 based on the CBIND failure status 💀
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
Table 8. PLOGI LS_RJT Status for CBIND Failures7.3.1.8. Read Exchange Concise (REC) 🍓
Link Service Request Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
| | (present only for translation type 3) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange OriginatorOther Special Processing:
None. 🧚
7.3.1.9. Read Exchange Concise Accept (REC ACC) ✨
ELS Format of the REC ACC Response 💖
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Originator Address Identifier |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Responder Address Identifier |
+------+------------+------------+-----------+----------+
| 4 | FC4VALUE (FC-4-Dependent Value) |
+------+------------+------------+-----------+----------+
| 5 | E_STAT (Exchange Status) |
+======+============+============+===========+==========+
| 6-7 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
| 8-9 |Port Name of the Exchange Responder (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Originator Address 1, 2, or 3 Port Name of the
Identifier Exchange Originator
Responder Address 1, 2, or 3 Port Name of the
Identifier Exchange ResponderOkay so, when there's supplemental data, the frame SHALL always be extended by 4 words, just like the diagram shows 🫶. And if the translation type for either the Originator Address Identifier or the Responder Address Identifier is 1 or 2, that matching 8-byte port name SHALL be set to all zeros 💅.
Other Special Processing: None. 🌸
7.3.1.10. Read Exchange Status Block (RES) 🦋
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
| 11-12| Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange OriginatorOther Special Processing: None. 🍓
7.3.1.11. Read Exchange Status Block Accept (RES ACC) 🎀
Format of ELS Accept Response:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Exchange Originator N_PORT ID |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Exchange Responder N_PORT ID |
+------+------------+------------+-----------+----------+
| 4 | Exchange Status Bits |
+------+------------+------------+-----------+----------+
| 5 | Reserved |
+------+------------+------------+-----------+----------+
| 6-n | Service Parameters and Sequence Statuses |
| | as described in [FC-FS] |
+======+============+============+===========+==========+
|n+1- | Port Name of the Exchange Originator (8 bytes) |
|n+2 | |
+======+============+============+===========+==========+
|n+3- | Port Name of the Exchange Responder (8 bytes) |
|n+4 | |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the
N_PORT ID Exchange Originator
Exchange Responder 1, 2, or 3 Port Name of the
N_PORT ID Exchange ResponderAlright bestie, so when supplemental data is needed, the ELS SHALL be extended by 4 words, same as above 💅. And if the translation type for the Exchange Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, the matching 8-byte port name SHALL be set to all zeros 🙈.
Other Special Processing: None. ✨
7.3.1.12. Read Link Error Status (RLS) 💜
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT Identifier |
+======+============+============+===========+==========+
| 2-3 | Port Name of the N_PORT (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
N_PORT Identifier 1, 2, or 3 Port Name of the
N_PORTOther Special Processing: None. 🌈
7.3.1.13. Read Sequence Status Block (RSS) 🧚
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | SEQ_ID | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange OriginatorOther Special Processing: None. 💀
7.3.1.14. Reinstate Recovery Qualifier (RRQ) 👑
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A
S_IDOther Special Processing: None. 🫶
7.3.1.15. Request Sequence Initiative (RSI) 🌸
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A
S_IDOther Special Processing: None. 🎀
7.3.1.16. Scan Remote Loop (SRL) 🔍
okay bestie, SRL lets you scan a remote loop to check whether the device configuration has changed ✨ Any change sets off a fibre channel state change notification, and then the iSNS database gets updated 💅
The ELS format looks like this 🎀
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x7B | Reserved |
+------+------------+------------+-----------+----------+
| 1 | Flag | Address Identifier of the FL_PORT |
| | | (see B.1) |
+======+============+============+===========+==========+
| 2-3 | Worldwide Name of the Remote FL_PORT |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Address Identifier 3 Worldwide Name of
of the FL_PORT the Remote FL_PORTOther Special Processing:
The D_ID field is the address of the Domain Controller for the remote loop, so it's giving very targeted 🎯 The Domain Controller address is FF FC || Domain_ID, where Domain_ID is the gateway-assigned alias for the remote gateway or switch element being queried 🧚 After the remote gateway translates it, the D_ID points at the gateway or switch element that gets scanned inside the remote gateway region 💜
The FLAG field sets the scope of the SRL 👑 If it's 0, every loop port interface on the given switch element or gateway gets scanned. If it's 1, the loop port interface on the gateway or switch element being scanned MUST be specified in bits 8 through 31 🔥
If the Flag field is 0, the SRL request SHALL NOT be sent as a special ELS 🙈
If the Domain_ID represents a remote switch or gateway and there's no iFCP session to the remote Domain Controller yet, the requesting gateway SHALL create the iFCP session 🫶
7.3.1.17. Third Party Process Logout (TPRLO)
TPRLO lets an N_PORT (the third party) remove one or more process login sessions between the destination N_PORT and the other N_PORTs named in the command 🦋 The command includes one or more TPRLO LOGOUT PARAMETER PAGEs. Each page, combined with the destination N_PORT, identifies one process login to terminate 💅
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+Figure 22. Format of TPRLO ELS
Each TPRLO parameter page holds parameters that identify one or more image pairs 🌸 It can be tied to a single FC-4 protocol type that's shared by all the FC-4 protocol types between the specified image pair, or it can be global to all the specified image pairs 🌈 A TPRLO page that needs address translation looks like Figure 23. More on TPRLO lives in [FC-FS] 📚
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-31 |
+------+------------+------------+-----------+----------+
| 0 | TYPE Code | TYPE CODE | |
| | or | EXTENSION | TPRLO Flags |
| | Common SVC | | |
| | Parameters | | |
+------+------------+------------+-----------+----------+
| 1 | Third Party Process Associator |
+------+------------+------------+-----------+----------+
| 2 | Responder Process Associator |
+------+------------+------------+-----------+----------+
| 3 | Reserved | Third Party Originator N_PORT ID |
+======+============+============+===========+==========+
| 4-5 | Worldwide Name of Third Party Originator |
| | N_PORT |
+------+------------------------------------------------+Figure 23. Format of an Augmented TPRLO Parameter Page
Here are the TPRLO flags that affect supplemented ELS processing 🧁
Bit 18: Third party Originator N_PORT Validity. When this is set to one, word 3, bits 8-31 (the Third Party Originator N_PORT ID) is meaningful 💖
Bit 19: Global Process logout. When this is set to one, all image pairs for all N_PORTs of the specified FC-4 protocol shall be invalidated 💀 When this bit is one, only one logout parameter page is permitted in the TPRLO payload.
If bit 18 is zero and bit 19 is one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS 🙅♀️
Otherwise, the originating gateway SHALL process the ELS like this ✨
a) The first word of the TPRLO payload SHALL NOT be modified 🙌
b) Each TPRLO parameter page shall be extended by two words, as shown in Figure 23 🧚
c) If word 0, bit 18 (Third Party Originator N_PORT ID validity) in the TPRLO flags field is one, then the sender shall put the worldwide port name of the fibre channel device's N_PORT into the extension words. The N_PORT ID SHALL be set to 3. Otherwise, the contents of the extension words and the Third Party Originator N_PORT ID SHALL be set to zero 🎀
d) The ELS originator SHALL set the SPC bit in the encapsulation header of each augmented frame that makes up the ELS (see Section 5.3.1) 💜
e) If the ELS contains a single TPRLO parameter page, the originator SHALL increase the frame length as needed to include the extended parameter page 🌷
f) If the ELS to be augmented contains multiple TPRLO parameter pages, the FC frames created to hold the augmented ELS payload SHALL NOT exceed the maximum frame size the destination N_PORT can accept 🛑
Each fibre channel frame SHALL contain a whole number of extended TPRLO parameter pages 🍓 The maximum number of extended TPRLO parameter pages in a frame SHALL be limited to however many fit without going over that upper limit. New frames made by extending the TPRLO pages to include the supplemental data SHALL be created by extending the SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT be modified 🫶
The gateway that receives the augmented TPRLO ELS SHALL generate ELS frames to send to the destination N_PORT. It does this by copying word 0 of the ELS payload and processing each augmented parameter page like so 🧠
a) If word 0, bit 18 is one, create a parameter page by copying words 0 through 2 of the augmented parameter page. The Third Party Originator N_PORT ID in word 3 shall be generated by looking at the supplemental data, as described in Section 7.2 ✨
b) If word 0, bit 18 is zero, create a parameter page by copying words 0 through 3 of the augmented parameter page 🌸
The size of each frame sent to the destination N_PORT MUST NOT exceed the maximum frame size that the destination N_PORT can accept 🔥 The sequence identifier in each frame header SHALL be copied from the augmented ELS, and the sequence count SHALL be monotonically increasing 🦋
7.3.1.18. Third Party Logout Accept (TPRLO ACC)
Here's the format of the TPRLO ACC frame 💅
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+Figure 24. Format of TPRLO ACC ELS
The parameter page format and the rules for augmenting it are the same as in Section 7.3.1.17 🎀
7.3.2. Special FC-4 Link Services
This is where we cover the FC-4 link services that need special processing 🧚
7.3.2.1. FC-4 Link Services Defined by FCP
The format of FC-4 link service frames defined by FCP is in [FCP-2] 📖
7.3.2.1.1. FCP Read Exchange Concise (FCP REC)
The payload format for this one is identical to the REC extended link service in Section 7.3.1.8, and it SHALL be processed the way that section describes 💖 The FC-4 version is going to become obsolete in [FCP-2]. But to support devices built against early revisions of FCP-2, an iFCP gateway MUST support both versions 🫶
7.3.2.1.2. FCP Read Exchange Concise Accept (FCP REC ACC)
The payload format for this one is identical to the REC ACC extended link service in Section 7.3.1.9, and it SHALL be processed as described in that section 🌈 The FC-4 version is going to become obsolete in [FCP-2]. But to support devices built against earlier revisions of FCP-2, an iFCP gateway MUST support both versions 👑
7.4. FLOGI Service Parameters Supported by an iFCP Gateway 🛫
okay so the FLOGI ELS is what an N_PORT sends when it wants to get into the fabric transport services. it's basically its big "hi, let me in" moment 💅
the FLOGI request and FLOGI ACC payloads are literally the same layout as the PLOGI request and ACC payloads from Section 7.3.1.7. no need to learn two different vibes 🫶
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 25. FLOGI Request and ACC Payload Formatevery parameter gets the full breakdown in [FC-FS], so go check there for the deep dive 🤓
this section is where we list which protocol-dependent service parameters a fabric port hooked up to an iFCP gateway actually supports. spoiler: it's a whole vibe check 🎀
the service parameters in the payload of an FLOGI extended link service request MUST be set in accordance with Table 9. no wiggle room bestie 🙈
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
Table 9. FLOGI Service Parameter Settingsthe notes that go with it:
- "n" means a parameter or capability the iFCP protocol does not support. so that's the "nope" column 🙅♀️
- "M" means an applicable parameter that an iFCP gateway MUST support. the "M" ones are non-negotiable, periodt 👑
8. iFCP Error Detection ✨
8.1. Overview
this section lays out extra provisions for error detection and recovery on top of the ones in [FC-FS]. those original ones keep working in the iFCP network environment too, so nothing gets left behind 🦋
8.2. Stale Frame Prevention 🌸
recovering from fibre channel protocol errors means the frames tied to a failed or aborted exchange have to drain out of the fabric before the exchange resources can be safely reused. makes sense, right? 🧚
a fibre channel fabric might not keep frames in order, so there's no deterministic way to purge those leftover frames. instead the fabric promises that a frame's lifetime won't go past a specific limit (R_A_TOV). the fabric is basically doing its own version of a time-out 💀
R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". for example, 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 link service request has to wait for the response to that request. the fibre channel default value for R_A_TOV is 10 seconds ⏰
an iFCP gateway SHALL actively enforce limits on R_A_TOV as described in Section 8.2.1. no slacking 🔥
8.2.1. Enforcing R_A_TOV Limits
the R_A_TOV limit on frame lifetimes SHALL be enforced using the time stamp in the encapsulation header (see Section 5.3.1), and this section explains how 🎀
the budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs, plus the propagation delay through the IP network. this last piece is called IP_TOV in this spec, so remember that name 💜
IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. it should be set to 50 percent of R_A_TOV. the math is giving balance ⚖️
the next paragraphs cover the rules for syncing gateway time bases and for measuring and enforcing propagation delay limits. let's get into it 💖
the protocol for syncing a gateway time base is SNTP [RFC2030]. to keep all the gateways time aligned, a gateway SHOULD get the address of an SNTP-compatible time server through an iSNS query. if the query gives back more than one time server address, the servers have to be synchronized and the gateway can use any server on the list. or the server may return a multicast group address to support operating in Anycast mode. Anycast mode is implemented as specified in [RFC2030], including the precautions that document defines. Multicast mode SHOULD NOT be used. not it 🙅♀️
an SNTP server can use any one of the time reference sources listed in [RFC2030]. the resolution of the time reference MUST be 125 milliseconds or better. that's a strict minimum, bestie ⏱️
stability of the SNTP server and gateway time bases should be 100 ppm or better. keep those clocks steady 🧘♀️
the gateway is always in one of two states when it comes to its time base: Synchronized or Unsynchronized. big moment, I know 😭
when the gateway is in the synchronized state, it SHALL
a) set the time stamp field for each outgoing frame according to the gateway's internal time base;
b) check the time stamp field of each incoming frame, once the encapsulation header CRC has been validated, as described in Section 5.3.4;
c) if the incoming frame has a time stamp of 0,0 and it isn't one of the session control frames that require a 0,0 time stamp (see Section 6), the frame SHALL be discarded;
d) if the incoming frame has a non-zero time stamp, the receiving gateway SHALL compute the absolute value of the time in flight and SHALL compare it against the value of IP_TOV specified for the IP fabric;
e) if the result in step (d) exceeds IP_TOV, the encapsulated frame shall be discarded. otherwise, the frame shall be de-encapsulated as described in Section 5.3.4. 🗑️
a gateway SHALL enter the Synchronized state as soon as it gets a successful response to an SNTP query. welcome to the sync squad 🎉
a gateway shall enter the Unsynchronized state:
a) upon power-up and before it successfully completes an SNTP query, and
b) whenever the gateway loses contact with the SNTP server, so that the gateway's time base may no longer line up with the SNTP server's. the criterion for deciding loss of contact is implementation specific. 🤷♀️
after losing contact, it is recommended that the gateway enter the Unsynchronized state when the estimated time base drift relative to the SNTP reference is greater than ten percent of the IP_TOV limit. (assuming all timers have an accuracy of 100 ppm and IP_TOV equals 5 seconds, the maximum allowable loss of contact duration would be about 42 minutes. that's a whole lunch break ☕)
when a gateway goes from Synchronized to Unsynchronized, it MUST abort all iFCP sessions as described in Section 5.2.3. and while it's Unsynchronized, a gateway SHALL NOT permit the creation of new iFCP sessions. no new sessions for you, not right now 🚫💅
9. Fabric Services Supported by an iFCP Implementation 👑
an iFCP gateway implementation MUST support the following fabric services:
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
0xFF-FF-FD Fabric Controller 9.2
0xFF-FF-FC Directory/Name Server 9.3on top of those, an iFCP gateway MAY support the FC broadcast server functionality described in Section 9.4. optional but iconic if you do 🌈
9.1. F_PORT Server
the F_PORT server SHALL support the FLOGI ELS, as described in Section 7.4, along with these ELSs specified in [FC-FS]:
a) Request for fabric service parameters (FDISC).
b) Request for the link error status (RLS).
c) Read Fabric Timeout Values (RTV).
9.2. Fabric Controller
the Fabric Controller SHALL support the following ELSs as specified in [FC-FS]:
a) State Change Notification (SCN).
b) Registered State Change Notification (RSCN).
c) State Change Registration (SCR).
9.3. Directory/Name Server
the Directory/Name server is the registration service that lets an N_PORT record info about other N_PORTs or query the database for it. the services are defined in [FC-GS3], and the queries are sent as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3]. 📇
in iFCP, each name server request MUST be translated into the matching iSNS query defined in [ISNS]. the definitions of name server objects are specified in [FC-GS3]. translation, but make it iconic 💖
the name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server), and it MAY support the FC-4 specific services as defined in [FC-GS3]. 🫶
9.4. Broadcast Server ✨
okay so fibre channel broadcasts work by addressing frames to the broadcast server at the well-known address 0xFF-FF-FF 📢. The broadcast server then copies the frame and delivers it to every attached N_PORT in all the zones the sending device belongs to 💅. Only class 3 (datagram) service is supported, no cap 🫶.
In an iFCP system, that broadcast function gets emulated with a two-tier setup 🦋 made of these pieces:
a) A local broadcast server living in each iFCP gateway. It spreads broadcast traffic within its own gateway region, and forwards outgoing broadcasts up to a global server so they get distributed across the whole iFCP fabric 🌸.
b) A global broadcast server that re-distributes broadcast traffic to the local server in each participating gateway ✨.
c) An iSNS discovery domain that defines the scope where broadcast traffic gets propagated. The discovery domain holds a global broadcast server and the set of local servers it supports 🧚.
Both the local and global broadcast servers are logical iFCP devices that talk using the iFCP protocol 💜. They have an N_PORT Network Address made of an iFCP portal address plus an N_PORT ID set to the well-known FC broadcast server address (0xFF-FF-FF) 🎀.
As noted above, an N_PORT starts a broadcast by sending frame traffic to the FC broadcast server. The gateway-resident local server delivers a copy locally, then forwards a copy to the global server so it can be redistributed to the local servers on other gateways 🌈. The global server MUST NOT echo a broadcast frame back to the originating local server 🙈.
9.4.1. Establishing the Broadcast Configuration
The broadcast configuration is managed with facilities from the iSNS server, in these ways 🍓:
a) An iSNS discovery domain gets created and seeded with the network address of the global broadcast server N_PORT. The global server is identified as such by setting the appropriate N_PORT entity attribute 👑.
b) Using the management interface, each broadcast server is preset with the identity of the broadcast domain 🫶.
During power up, each gateway SHALL invoke the iSNS service to register its local broadcast server in the broadcast discovery domain. After registration, the local server SHALL wait for the global broadcast server to establish an iFCP session ✨.
The global server SHALL register with the iSNS server like this 💅:
a) The server SHALL query the iSNS name server by attribute to get the worldwide port name of the N_PORT that's pre-configured to provide global broadcast services.
b) If the worldwide port name obtained above does not correspond to that of the server issuing the query, the N_PORT SHALL NOT perform global broadcast functions for N_PORTs in that discovery domain. Basically it just sits out the global broadcast job for that domain 💀.
c) Otherwise, the global server N_PORT SHALL register with the discovery domain and query the iSNS server to identify all currently registered local servers.
d) The global broadcast server SHALL initiate an iFCP session with each local broadcast server in the domain. When a new local server registers, the global server SHALL receive a state change notification and respond by initiating an iFCP session with the newly added server. The gateway SHALL obtain these notifications using the iSNS provisions for lossless delivery 🔥.
Upon receiving the CBIND request to initiate the iFCP session, the local server SHALL record the worldwide port name and N_PORT network address of the global server 🧚.
9.4.2. Broadcast Session Management
After the initial broadcast session is established, the local or global broadcast server MAY choose to manage the session in one of the following ways, depending on resource requirements and the anticipated level of broadcast traffic 🦋:
a) A server MAY keep the session open continuously. Since broadcast sessions are often quiescent for long periods of time, the server SHOULD monitor session connectivity as described in Section 5.2.2.4 💜.
b) A server MAY open the broadcast session on demand only when broadcast traffic is to be sent. If the session is reopened by the global server, the local server SHALL replace the previously recorded network address of the global broadcast server 🌸.
9.4.3. Standby Global Broadcast Server
An implementation may designate a local server to assume the duties of the global broadcast server if something fails 🛟. The local server may use the LTEST message to check whether the global server is functioning, and may take over control if it isn't 🌈.
When assuming control, the standby server must register with the iSNS server as the global broadcast server in place of the failed server, and must install itself in the broadcast discovery domain as specified in steps c) and d) of Section 9.4.1 🫶.
10. iFCP Security ✨
10.1. Overview
iFCP leans on the IPSec protocol suite for data confidentiality and authentication, and it uses IKE as its key management protocol 🔐. Section 10.2 covers the security requirements that come from iFCP's operating environment, and Section 10.3 covers the resulting design choices, their requirement levels, and how they apply to the iFCP protocol 💖.
Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS] 🎀.
10.2. iFCP Security Threats and Scope
10.2.1. Context
iFCP is built for gateway devices deployed in enterprise data centers 🏢. Those environments usually have security gateways that provide network security by isolating the network from public networks 🛡️. And iFCP data may have to go through security gateways to support SAN-to-SAN connectivity across public networks 🌍.
10.2.2. Security Threats
Communicating iFCP gateways may be subjected to attacks, including attempts by an adversary to 😤:
a) acquire confidential data and identities by snooping data packets,
b) modify packets containing iFCP data and control messages,
c) inject new packets into the iFCP session,
d) hijack the TCP connection carrying the iFCP session,
e) launch denial-of-service attacks against the iFCP gateway,
f) disrupt the security negotiation process,
g) impersonate a legitimate security gateway, or
h) compromise communication with the iSNS server.
It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole fibre channel island, which may include several hosts and fibre channel switches 🏝️. To do so, the iFCP gateway must implement and may use confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. The iFCP gateway must implement and may use bi-directional authentication of the communication endpoints. Finally, it must implement and may use a scalable approach to key management ✨.
10.2.3. Interoperability with Security Gateways
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats 🚨. Such networks are usually protected by security gateways, which, at a minimum, provide a shield against denial-of-service attacks. The iFCP security architecture is capable of leveraging the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways 🧱. Considerations regarding intervening NAT and NAPT boxes along the iFCP-iSNS path can be found in [ISNS].
10.2.4. Authentication
iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either peer gateway or both. Consequently, bi-directional authentication of peer gateways must be provided in accordance with the requirement levels specified in Section 10.3.1 🤝.
N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated if the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection.
There is no requirement that the identities used in authentication be kept confidential.
10.2.5. Confidentiality
iFCP traffic may traverse insecure public networks, and therefore implementations must have per-packet encryption capabilities to provide confidentiality in accordance with the requirements specified in Section 10.3.1 🔒.
10.2.6. Rekeying
Due to the high data transfer rates and the amount of data involved, an iFCP implementation must support the capability to rekey each phase 2 security association in the time intervals dictated by sequence number space exhaustion at a given link rate. In the rekeying scenario described in [SECIPS], for example, rekeying events happen as often as every 27.5 seconds at a 10 Gbps rate ⚡.
The iFCP gateway must provide the capability for forward secrecy in the rekeying process.
10.2.7. Authorization
Basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and certificate-based authentication (e.g., with X509v3 certificates) enables authorization schemas of increasing complexity. The definition of such schemas (e.g., role-based access control) is outside of the scope of this specification 🗝️.
10.2.8. Policy Control
This specification allows any and all security mechanisms in an iFCP gateway to be administratively disabled. Security policies MUST have, at most, iFCP Portal resolution. Administrators may gain control over security policies through an adequately secured interaction with a management interface or with iSNS 👑.
10.2.9. iSNS Role
iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways MUST use iSNS for discovery services and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms for securing communication between an iFCP gateway and iSNS server(s). Additionally, the specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s) 💅.
10.3. iFCP Security Design ✨
10.3.1. Enabling Technologies ✨
Okay so, IPsec and IKE come with a whole suite of specs, and these are the ones you need to know 🫶:
- [RFC2401] Security Architecture for the Internet Protocol
- [RFC2402] IP Authentication Header
- [RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH
- [RFC2405] The ESP DES-CBC Cipher Algorithm with Explicit IV
- [RFC2406] IP Encapsulating Security Payload
- [RFC2407] The Internet IP Security Domain of Interpretation for ISAKMP
- [RFC2408] Internet Security Association and Key Management Protocol (ISAKMP)
- [RFC2409] The Internet Key Exchange (IKE)
- [RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
- [RFC2451] The ESP CBC-Mode Cipher Algorithms
- [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
Now the implementation rules, and yes, they matter a lot 💅. Supporting IP Encapsulating Security Payload (ESP) [RFC2406] is mandatory to implement. When ESP is used, per-packet data origin authentication, integrity, and replay protection MUST be used. Main character energy for security, no cap 🔥.
For data origin authentication and integrity with ESP, HMAC with SHA1 [RFC2404] MUST be implemented. The Advanced Encryption Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining SHOULD be implemented in accordance with [AESCBC].
For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be implemented, and AES counter mode encryption [AESCTR] SHOULD be implemented. NULL encryption MUST be supported as well, as defined in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its inherent weakness. It's known to be crackable with modest computation resources, so it is inappropriate for use in any iFCP deployment scenario 💀.
A conforming iFCP protocol implementation MUST implement IPsec ESP [RFC2406] in tunnel mode [RFC2401], and it MAY implement IPsec ESP in transport mode.
Regarding key management, iFCP implementations MUST support IKE [RFC2409] for bi-directional peer authentication, negotiation of security associations, and key management, using the IPsec DOI. There is no requirement that the identities used in authentication be kept confidential. Manual keying MUST NOT be used, since it doesn't provide the necessary keying support. According to [RFC2409], pre-shared secret key authentication is mandatory to implement, whereas certificate-based peer authentication using digital signatures MAY be implemented (see Section 10.3.3 regarding the use of certificates) 🎀.
[RFC2409] defines the following requirement levels for IKE Modes, so pay attention bestie:
- Phase-1 Main Mode MUST be implemented.
- Phase-1 Aggressive Mode SHOULD be implemented.
- Phase-2 Quick Mode MUST be implemented.
- Phase-2 Quick Mode with key exchange payload MUST be implemented.
With iFCP, Phase-1 Main Mode SHOULD NOT be used together with pre-shared keys. Main Mode is vulnerable to man-in-the-middle attackers when group pre-shared keys are used, and that is so not it 🙈. In this scenario, Aggressive Mode SHOULD be used instead. Peer authentication using the public key encryption methods outlined in [RFC2409] SHOULD NOT be used.
The DOI [RFC2407] provides for several types of Identification Payloads 🧚.
When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conforming iFCP implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), or ID_FQDN Identification Type values. The ID_USER_FQDN, IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Type values SHOULD NOT be used. The ID_KEY_ID Identification Type values MUST NOT be used. As described in [RFC2407], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the Identification Payload fields (IDci and IDcr). Conforming iFCP implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values, depending on the version of IP supported. Other Identification Type values MUST NOT be used. As described in Section 5.2.2, the gateway creating the iFCP session must query the iSNS server to find the right port to start the associated TCP connection on. Upon a successful IKE Phase 2 exchange, the IKE responder enforces the negotiated selectors on the IPsec SAs. Any later iFCP session creation requires the iFCP peer to query its iSNS server for access control, following the session creation requirements in Section 5.2.2.1 ✨.
10.3.2. Use of IKE and IPsec
A conforming iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized, or it may be deferred until the first TCP connection with security requirements is established 🦋.
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, a successful establishment of an IKE Phase-2 SA creates two uni-directional IPsec SAs, fully qualified by the tuple <SPI, destination IP address, ESP>.
These SAs protect the setup process of the underlying TCP connections and all of their later TCP traffic. The number of TCP connections in an IPsec SA, and the number of SAs, is mostly driven by security policy considerations (security services are defined at the granularity of an IPsec SA only), QoS considerations (for example, multiple QoS classes within the same IPsec SA increase the odds of packet reordering, possibly falling outside the replay window), and failure compartmentalization considerations. Each TCP connection protected by an IPsec SA is either in the unbound state or bound to a specific iFCP session 🌸.
In summary, at any point in time:
-- there exist 0..M IKE Phase-1 SAs between peer iFCP portals,
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
-- each IKE Phase-2 SA protects 0..Z TCP connections.The creation of an IKE Phase-2 SA may be triggered by a policy rule supplied through a management interface, or by iFCP Portal properties registered with the iSNS server. Similarly, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface or by an iFCP Portal policy rule registered with the iSNS server 👑.
If an iFCP implementation makes use of unbound TCP connections, and those connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times, just like bound connections.
Upon receipt of an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. An IKE Phase-2 SA may be associated with multiple TCP connections, so terminating those connections might in fact be inappropriate and untimely 😭.
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data needs to be sent over the connections 🍓.
10.3.3. Signatures and Certificate-Based Authentication
Conforming iFCP implementations MAY support peer authentication via digital signatures and certificates. When certificate authentication is chosen within IKE, each iFCP gateway needs the certificate credentials of each peer iFCP gateway in order to establish a security association with that peer 🔐.
Certificate credentials used by iFCP gateways MUST be those of the machine. Certificate credentials MAY be bound to the interface (IP Address or FQDN) of the iFCP gateway used for the iFCP session, or to the fabric WWN of the iFCP gateway itself. The value of a machine certificate is inversely proportional to how easily an attacker can get one under false pretenses, so it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. User certificates SHOULD NOT be used by iFCP gateways to establish SAs protecting iFCP sessions 💅.
If the gateway does not have the peer iFCP gateway's certificate credentials, it can get them in either of these ways:
a) by using the iSNS protocol to query for the peer gateway's certificate(s) stored in a trusted iSNS server, or
b) through use of the ISAKMP Certificate Request Payload (CRP) [RFC2408] to request the certificate(s) directly from the peer iFCP gateway.
When certificate chains are long enough, IKE exchanges using UDP as the underlying transport may yield IP fragments. Those fragments are known to work poorly across some intervening routers, firewalls, and NA(P)T boxes, so the endpoints may be unable to establish an IPsec security association 😬.
Because of these fragmentation shortcomings, IKE is most appropriate for intra-domain usage. Known solutions to the fragmentation problem include sending the end-entry machine certificate rather than the chain, reducing the size of the certificate chain, using IKE implementations over a reliable transport protocol (e.g., TCP) assisted by Path MTU discovery and code against black-holing as per [RFC2923], or installing network components that can properly handle fragments 🦋.
IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) [RFC2408] before accepting a certificate for use in IKE's authentication procedures ✨.
10.4. iSNS and iFCP Security
iFCP implementations MUST use iSNS for discovery and management services. That means the security of the iSNS protocol affects the security of iFCP gateways too, so it's a big deal 🚨. For a discussion of potential threats to iFCP gateways through use of iSNS, see [ISNS].
To provide security for iFCP gateways using the iSNS protocol for discovery and management services, the IPSec ESP protocol in tunnel mode MUST be supported for iFCP gateways. Further discussion of iSNS security implementation requirements is found in [ISNS]. Note that iSNS security requirements match those for iFCP described in Section 10.3 🔥.
10.5. Use of iSNS to Distribute Security Policy
Once communication between iFCP gateways and the iSNS server has been secured through IPSec, the iFCP gateways can discover the security settings they need to use (or not use) to protect iFCP traffic. That's a potential scaling win over configuring security policies one device at a time for each iFCP gateway 🌈. It also gives each iFCP gateway an efficient way to discover whether peer gateways use or don't use specific security capabilities 💜.
Further discussion on using iSNS to distribute security policies is found in [ISNS].
10.6. Minimal Security Policy for an iFCP Gateway ✨
okay bestie, so an iFCP implementation can actually switch off its security mechanisms for an iFCP Portal 🙅♀️. It can do that administratively through a management interface, or through security policy elements set in the iSNS server. And the consequence? IKE or IPsec security associations won't get established for any iFCP sessions that traverse the portal 😭.
Here's the thing: for most IP networks it's lowkey sus to assume physical security, administrative security, and correct configuration of the network and every attached node 🙈. (A physically isolated network in a test lab might be the exception 🧪.) So authentication SHOULD be used to get at least minimal assurance that connections were opened with the intended counterpart 🫶. The minimal iFCP security policy only says that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS] 💜.
11. Quality of Service Considerations 🌈
11.1. Minimal Requirements
Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway, even across one or more intervening best-effort IP regions 💖. The timings for that gateway-to gateway communication, though, will depend a LOT on BER, packet losses, latency, and jitter across the best-effort IP regions 📉. The higher these parameters get, the bigger the gap between iFCP observed behaviors and baseline iFCP behaviors (the ones produced by two iFCP gateways directly connected to each other) 🍓.
11.2. High Assurance
Many iFCP deployments are expected to benefit from a high degree of assurance about how the intervening IP regions behave 👑. That gives high assurance on the overall end-to-end path, as fibre channel applications directly experience it ✨. The assurance on IP behaviors comes from intervening IP regions supporting standard Quality-of-Service (QoS) techniques that fully complement iFCP, such as:
- a) congestion avoidance by over-provisioning of the network,
- b) integrated Services [RFC1633] QoS,
- c) differentiated Services [RFC2475] QoS, and
- d) Multi-Protocol Label Switching [RFC3031].
You can load an MPLS forwarding equivalence class (FEC) with QoS class significance, on top of other stuff like protection and diversity for the given path 🦋. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], where the PHB bits get copied to the EXP bits of the MPLS shim header 🔥.
In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions that implement some of the QoS solutions above 🧚. A QoS-capable IP region supports negotiating and establishing a service contract that specifies the forwarding service through the region 💅. That contract and its negotiation rules are outside the scope of this document 🙅♀️. For IP regions with DiffServ QoS, the reader should refer to Service Level Specifications (SLS) and Traffic Conditioning Specifications (TCS) (as defined in [DIFTERM]) 📖. Other aspects of a service contract are expected to be non-technical, so they're outside the IETF scope 🫠.
Fibre channel Class 2 and Class 3 don't currently support fractional bandwidth guarantees, and iFCP is committed to supporting fibre channel semantics. So it's impossible for an iFCP gateway to infer bandwidth requirements on its own from streaming fibre channel traffic 😭. Instead, the requirements on bandwidth or other network parameters need to be administratively set into an iFCP gateway, or into the entity that will actually negotiate the forwarding service on the gateway's behalf 📝. Depending on the QoS techniques available, stipulating a forwarding service may require interaction with network ancillary functions, like admission control and bandwidth brokers (via RSVP or other signaling protocols that an IP region may accept) 🎀.
The administrator of an iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of the gateway's TCP sessions. Alternately, that responsibility may be delegated to a node downstream 🌸. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP-unaware network equipment too 👀.
To get the best emulation of fibre channel over IP, typical forwarding services are expected to specify a fixed amount of bandwidth, null losses, and, to a lesser degree, low latency and low jitter 💜. For example, an IP region using DiffServ QoS may support SLSes like this by applying EF DSCPs to the iFCP traffic 🫶.
12. IANA Considerations 🧾
The IANA-assigned port for iFCP traffic is port number 3420 🔢.
An iFCP Portal may initiate a connection using any TCP port number that fits its implementation of the TCP/IP stack, as long as each port number is unique 🦋. To prevent receiving stale data from a previous connection on a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed 🙈.
13. Normative References 📚
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M.,
Monia, C., and M. Merhar, "Fibre Channel (FC) Frame
Encapsulation", RFC 3643, December 2003.
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling
(FC-FS), Rev 1.70, INCITS Project 1331D, February 2002
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
GS3)", revision 7.01, INCITS Project 1356-D, November 2000
[FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC-
SW2)", revision 5.2, INCITS Project 1305-D, May 2001
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second
Version", revision 8, INCITS Project 1144D, September 2002
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and
J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171,
September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, N.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols Over IP", RFC
3723, April 2004.14. Informative References 🧠
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)",
Draft, 2001, Available from
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[DIFTERM] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL-
2)", revision 7.0, NCITS Project 1133D, April 1999
[FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC-
FLA)", revision 2.7, NCITS Project 1235-D, August 1997
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface
Architecture Mapping Protocol (FC-VI)", NCITS Project
1332-D, July 2000.
[KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated
Loop", Robert W. Kembel, Northwest Learning Associates,
2000, ISBN 0-931836-84-0
[KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction",
Northwest Learning Associates Inc., 2000, ISBN
0-931836-84-0
[MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June
1994.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated Service",
RFC 2475, December 1998.
[RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.Appendix A. iFCP Support for Fibre Channel Link Services 🎀
For reference, this appendix lists all the fibre channel link services and how each shall be processed by an iFCP implementation 📋. The iFCP processing policies are defined in Section 7 💅.
In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic that identifies the protocol 🫶.
A.1. Basic Link Services ✨
okay bestie, the basic link services table is literally where it starts 💅 Here's the whole thing, iFCP policy column and all:
Basic Link Services
Name Description iFCP Policy
---- ----------- ----------
ABTS Abort Sequence Transparent
BA_ACC Basic Accept Transparent
BA_RJT Basic Reject Transparent
NOP No Operation Transparent
PRMT Preempted Rejected
(Applies to
Class 1 only)
RMC Remove Connection Rejected
(Applies to
Class 1 only)A.2. Pass-Through Link Services 🫶
okay so per Section 7, the link service requests in Table 10 and their associated ACC response frames MUST get passed to the receiving N_PORT without altering the payload. no cap, that's the whole vibe 🌸
Name Description
---- -----------
ADVC Advise Credit
CSR Clock Synchronization Request
CSU Clock Synchronization Update
ECHO Echo
ESTC Estimate Credit
ESTS Establish Streaming
FACT Fabric Activate Alias_ID
FAN Fabric Address Notification
FCP_RJT FCP FC-4 Link Service Reject
FCP SRR FCP Sequence Retransmission
Request
FDACT Fabric Deactivate Alias_ID
FDISC Discover F_Port Service
Parameters
FLOGI F_Port Login
GAID Get Alias_ID
LCLM Login Control List Management
LINIT Loop Initialize
LIRR Link Incident Record
Registration
LPC Loop Port Control
LS_RJT Link Service Reject
LSTS Loop Status
NACT N_Port Activate Alias_ID
NDACT N_Port Deactivate Alias_ID
PDISC Discover N_Port Service
Parameters
PRLI Process Login
PRLO Process Logout
QoSR Quality of Service Request
RCS Read Connection Status
RLIR Registered Link Incident
Report
RNC Report Node Capability
RNFT Report Node FC-4 Types
RNID Request Node Identification
Data
RPL Read Port List
RPS Read Port Status Block
RPSC Report Port Speed
Capabilities
RSCN Registered State Change
Notification
RTV Read Timeout Value
RVCS Read Virtual Circuit Status
SBRP Set Bit-Error Reporting
Parameters
SCN State Change Notification
SCR State Change Registration
TEST Test
TPLS Test Process Login State
Table 10. Pass-Through Link ServicesA.3. Special Link Services 🧚
the extended and FC-4 link services in Table 11 get processed by an iFCP implementation the way the sections referenced in the table describe. slay, that's a clean handoff 💖
Name Description Section
---- ----------- -------
ABTX Abort Exchange 7.3.1.1
ADISC Discover Address 7.3.1.2
ADISC Discover Address Accept 7.3.1.3
ACC
FARP- Fibre Channel Address 7.3.1.4
REPLY Resolution Protocol
Reply
FARP- Fibre Channel Address 7.3.1.5
REQ Resolution Protocol
Request
LOGO N_PORT Logout 7.3.1.6
PLOGI Port Login 7.3.1.7
REC Read Exchange Concise 7.3.1.8
REC ACC Read Exchange Concise 7.3.1.9
Accept
FCP REC FCP Read Exchange 7.3.2.1.1
Concise (see [FCP-2])
FCP REC FCP Read Exchange 7.3.2.1.2
ACC Concise Accept (see
[FCP-2])
RES Read Exchange Status 7.3.1.10
Block
RES ACC Read Exchange Status 7.3.1.11
Block Accept
RLS Read Link Error Status 7.3.1.12
Block
RRQ Reinstate Recovery 7.3.1.14
Qualifier
RSI Request Sequence 7.3.1.15
Initiative
RSS Read Sequence Status 7.3.1.13
Block
SRL Scan Remote Loop 7.3.1.16
TPRLO Third Party Process 7.3.1.17
Logout
TPRLO Third Party Process 7.3.1.18
ACC Logout Accept
Table 11. Special Link ServicesAppendix B. Supporting the Fibre Channel Loop Topology 🌈
okay so a loop topology may be optionally supported by a gateway implementation in one of these two ways:
- a) By implementing the FL_PORT public loop interface specified in [FC-FLA].
- b) By emulating the private loop environment specified in [FC-AL2].
Private loop emulation lets fibre channel devices that don't support fabrics or public loops still attach. The gateway shows those devices to the fabric as though they were fabric-attached. And the other way round: the gateway shows devices on the fabric, whether they're attached locally or remotely, as though they were connected to the private loop. the way that's giving two-way street 🦋
Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session. not me being strict, but this part is non-negotiable 🙈
B.1. Remote Control of a Public Loop 👑
so a gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier, which is how the public loop may be remotely controlled. iykyk 🎀
The LFA and FL_PORT address identifier both represent an N_PORT that handles remote loop management requests carried in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias, so the matching alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero. literally the cutest little trick 😭
Acknowledgements ✨
The authors are indebted to everyone who contributed material and took the time to carefully review and critique this specification, including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel). the squad really showed up for this one 🫶
Author's Addresses 💌
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
Charles Monia 7553 Morevern Circle San Jose, CA 95135
EMail: charles_monia@yahoo.com
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Phone: 978-288-7708 EMail: travos@nortel.com
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
Phone: +44 (0)117 930 9600 EMail: mark_edwards@adaptec.com
Full Copyright Statement 📜
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ⚖️
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. and that's the end of RFC 4172, bestie 🦋✨
📦 where this page comes from
- ietf: rfc4172 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms