8. iFCP Error Detection
This section specifies provisions for error detection and recovery in
addition to those in [FC-FS], which continue to be available in the
iFCP network environment.
8.2. Stale Frame Prevention
Recovery from fibre channel protocol error conditions requires that
frames associated with a failed or aborted exchange drain from the
fabric before exchange resources can be safely reused.
Since a fibre channel fabric may not preserve frame order, there is
no deterministic way to purge such frames. Instead, the fabric
guarantees that frame the lifetime will not exceed a specific limit
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, a value of 2 x R_A_TOV is the minimum time
that the originator of an ELS request or FC-4 link service request
must 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.
8.2.1. Enforcing R_A_TOV Limits
The R_A_TOV limit on frame lifetimes SHALL be enforced by means of
the time stamp in the encapsulation header (see Section 5.3.1) as
described in this section.
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
latter component is referred to in this specification as IP_TOV.
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. IP_TOV
should be set to 50 percent of R_A_TOV.
The following paragraphs describe the requirements for synchronizing
gateway time bases and the rules for measuring and enforcing
propagation delay limits.
The protocol for synchronizing a gateway time base is SNTP [RFC2030].
In order to ensure that all gateways are time aligned, a gateway
SHOULD obtain the address of an SNTP-compatible time server via an
iSNS query. If multiple time server addresses are returned by the
query, the servers must be synchronized and the gateway may use any
server in the list. Alternatively, the server may return a multicast
group address in support of operation in Anycast mode.
Implementation of Anycast mode is as specified in [RFC2030],
including the precautions defined in that document. Multicast mode
SHOULD NOT be used.
An SNTP server may use any one of the time reference sources listed
in [RFC2030]. The resolution of the time reference MUST be 125
milliseconds or better.
Stability of the SNTP server and gateway time bases should be 100 ppm
With regard to its time base, the gateway is in either the
Synchronized or Unsynchronized state.
When in the synchronized state, the gateway SHALL
a) set the time stamp field for each outgoing frame in accordance
with the gateway's internal time base;
b) check the time stamp field of each incoming frame, following
validation of the encapsulation header CRC, as described in
c) if the incoming frame has a time stamp of 0,0 and is not 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
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 upon receiving a
successful response to an SNTP query.
A gateway shall enter the Unsynchronized state:
a) upon power-up and before successful completion of an SNTP query,
b) whenever the gateway looses contact with the SNTP server, such
that the gateway's time base may no longer be in alignment with
that of the SNTP server. The criterion for determining loss of
contact is implementation specific.
Following loss of 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 that 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.)
As the result of a transition from the Synchronized to the
Unsynchronized state, a gateway MUST abort all iFCP sessions as
described in Section 5.2.3. While in the Unsynchronized state, a
gateway SHALL NOT permit the creation of new iFCP sessions.
9. Fabric Services Supported by an iFCP Implementation
An iFCP gateway implementation MUST support the following fabric
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.3
In addition, an iFCP gateway MAY support the FC broadcast server
functionality described in Section 9.4.
9.1. F_PORT Server
The F_PORT server SHALL support the FLOGI ELS, as described in
Section 7.4, as well as the following 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
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 provides a registration service allowing an
N_PORT to record or query the database for information about other
N_PORTs. The services are defined in [FC-GS3]. The queries are
issued as FC-4 transactions using the FC-CT command transport
protocol specified in [FC-GS3].
In iFCP, each name server request MUST be translated to the
appropriate iSNS query defined in [ISNS]. The definitions of name
server objects are specified in [FC-GS3].
The name server SHALL support record and query operations for
directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and
MAY support the FC-4 specific services as defined in [FC-GS3].
9.4. Broadcast Server
Fibre channel frames are broadcast throughout the fabric by
addressing them to the fibre channel broadcast server at the well-
known fibre channel address 0xFF-FF-FF. The broadcast server then
replicates and delivers the frame to each attached N_PORT in all
zones to which the originating device belongs. Only class 3
(datagram) service is supported.
In an iFCP system, the fibre channel broadcast function is emulated
by means of a two-tier architecture comprising the following
a) A local broadcast server residing in each iFCP gateway. The local
server distributes broadcast traffic within the gateway region and
forwards outgoing broadcast traffic to a global server for
distribution throughout the 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 defining the scope over which broadcast
traffic is propagated. The discovery domain is populated with a
global broadcast server and the set of local servers it supports.
The local and global broadcast servers are logical iFCP devices that
communicate using the iFCP protocol. The servers have an N_PORT
Network Address consisting of an iFCP portal address and an N_PORT ID
set to the well-known fibre channel address of the FC broadcast
As noted above, an N_PORT originates a broadcast by directing frame
traffic to the fibre channel broadcast server. The gateway-resident
local server distributes a copy of the frame locally and forwards a
copy to the global server for redistribution to the local servers on
other gateways. The global server MUST NOT echo a broadcast frame to
the originating local server.
9.4.1. Establishing the Broadcast Configuration
The broadcast configuration is managed with facilities provided by
the iSNS server by the following means:
a) An iSNS discovery domain is 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
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 as follows:
a) The server SHALL query the iSNS name server by attribute to obtain
the worldwide port name of the N_PORT 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.
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
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 in the event of a failure. The local
server may use the LTEST message to determine whether the global
server is functioning and may assume control if it is not.
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
iFCP relies upon the IPSec protocol suite to provide data
confidentiality and authentication services, and it relies upon IKE
as the key management protocol. Section 10.2 describes the security
requirements arising from iFCP's operating environment, and Section
10.3 describes 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
iFCP is a protocol designed for use by gateway devices deployed in
enterprise data centers. Such environments typically have security
gateways designed to provide network security through isolation from
public networks. Furthermore, iFCP data may have to traverse
security gateways in order to support SAN-to-SAN connectivity across
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].
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
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.
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.
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
10.3. iFCP Security Design
10.3.1. Enabling Technologies
Applicable technology from IPsec and IKE is defined in the following
suite of specifications:
[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
[RFC2408] Internet Security Association and Key Management
[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
The implementation of IPsec and IKE is required according to the
Support for the 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.
For data origin authentication and integrity with ESP, HMAC with SHA1
[RFC2404] MUST be implemented, and 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. Since it is known to be crackable with modest computation
resources, it is inappropriate for use in any iFCP deployment
A conforming iFCP protocol implementation MUST implement IPsec ESP
[RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in
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 does not
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:
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 in conjunction with
pre-shared keys, due to Main Mode's vulnerability to man-in-the-
middle-attackers when group pre-shared keys are used. 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
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,
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 (according to 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 determine the appropriate port on which
to initiate the associated TCP connection. Upon a successful IKE
Phase 2 exchange, the IKE responder enforces the negotiated selectors
on the IPsec SAs. Any subsequent iFCP session creation requires the
iFCP peer to query its iSNS server for access control (in accordance
with the session creation requirements specified in Section 188.8.131.52).
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 may be
deferred until the first TCP connection with security requirements is
An IKE Phase-2 SA protects one or more TCP connections within the
same iFCP Portal. More specifically, the successful establishment of
an IKE Phase-2 SA results in the creation of two uni-directional
IPsec SAs fully qualified by the tuple <SPI, destination IP address,
These SAs protect the setup process of the underlying TCP connections
and all their subsequent TCP traffic. The number of TCP connections
in an IPsec SA, as well as the number of SAs, is practically driven
by security policy considerations (i.e., security services are
defined at the granularity of an IPsec SA only), QoS considerations
(e.g., multiple QoS classes within the same IPsec SA increase odds of
packet reordering, possibly falling outside the replay window), and
failure compartmentalization considerations. Each of the TCP
connections 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
such 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. Since an IKE Phase-2 SA may be associated
with multiple TCP connections, terminating these 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 are to be sent over the
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. Since the value of a
machine certificate is inversely proportional to the ease with which
an attacker can obtain one under false pretenses, 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 for establishment of SAs
protecting iFCP sessions.
If the gateway does not have the peer iFCP gateway's certificate
credentials, then it can obtain them:
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
When certificate chains are long enough, IKE exchanges using UDP as
the underlying transport may yield IP fragments, which are known to
work poorly across some intervening routers, firewalls, and NA(P)T
boxes. As a result, the endpoints may be unable to establish an
IPsec security association.
Due to 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
IKE negotiators SHOULD check the pertinent Certificate Revocation
List (CRL) [RFC2408] before accepting a certificate for use in IKE's
10.4. iSNS and iFCP Security
iFCP implementations MUST use iSNS for discovery and management
services. Consequently, the security of the iSNS protocol has an
impact on the security of iFCP gateways. 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.5. Use of iSNS to Distribute Security Policy
Once communication between iFCP gateways and the iSNS server has been
secured through use of IPSec, the iFCP gateways have the capability
to discover the security settings that they need to use (or not use)
to protect iFCP traffic. This provides a potential scaling advantage
over device-by-device configuration of individual security policies
for each iFCP gateway. It also provides an efficient means for each
iFCP gateway to discover the use or non-use of specific security
capabilities by peer gateways.
Further discussion on use of iSNS to distribute security policies is
found in [ISNS].
10.6. Minimal Security Policy for an iFCP Gateway
An iFCP implementation may be able to disable security mechanisms for
an iFCP Portal administratively through a management interface or
through security policy elements set in the iSNS server. As a
consequence, IKE or IPsec security associations will not be
established for any iFCP sessions that traverse the portal.
For most IP networks, it is inappropriate to assume physical
security, administrative security, and correct configuration of the
network and all attached nodes (a physically isolated network in a
test lab may be an exception). Therefore, authentication SHOULD be
used in order to provide minimal assurance that connections have
initially been opened with the intended counterpart. The minimal
iFCP security policy only states 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 with which such gateway-to gateway
communication is performed, however, will greatly depend upon BER,
packet losses, latency, and jitter experienced throughout the best-
effort IP regions. The higher these parameters, the higher the gap
measured between iFCP observed behaviors and baseline iFCP behaviors
(i.e., as produced by two iFCP gateways directly connected to one
11.2. High Assurance
It is expected that many iFCP deployments will benefit from a high
degree of assurance regarding the behavior of intervening IP regions,
with resulting high assurance on the overall end-to-end path, as
directly experienced by fibre channel applications. Such assurance
on the IP behaviors stems from the intervening IP regions supporting
standard Quality-of-Service (QoS) techniques that are fully
complementary to 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].
One may load an MPLS forwarding equivalence class (FEC) with QoS
class significance, in addition to other considerations such as
protection and diversity for the given path. The complementarity and
compatibility of MPLS with Differentiated Services is explored in
[MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS
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 mentioned above. A QoS-capable IP region supports
the negotiation and establishment of a service contract specifying
the forwarding service through the region. Such contract and
negotiation rules are outside the scope of this document. In the
case of 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 and thus are
outside of the IETF scope.
Because fibre channel Class 2 and Class 3 do not currently support
fractional bandwidth guarantees, and because iFCP is committed to
supporting fibre channel semantics, it is impossible for an iFCP
gateway to infer bandwidth requirements autonomously from streaming
fibre channel traffic. Rather, 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, the stipulation of a forwarding service may
require interaction with network ancillary functions, such as
admission control and bandwidth brokers (via RSVP or other signaling
protocols that an IP region may accept).
The administrator of a iFCP gateway may negotiate a forwarding
service with IP region(s) for one, several, or all of an iFCP
gateway's TCP sessions used by an iFCP gateway. Alternately, this
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 as well.
For rendering the best emulation of fibre channel possible over IP,
it is anticipated that typical forwarding services will specify a
fixed amount of bandwidth, null losses, and, to a lesser degree of
relevance, low latency and low jitter. For example, an IP region
using DiffServ QoS may support SLSes of this nature 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
consistent with its implementation of the TCP/IP stack, provided each
port number is unique. To prevent the receipt of stale data
associated with a previous connection using 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,
[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
[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
[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 purposes, this appendix enumerates all the fibre
channel link services and the manner in which 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 identifying the
A.1. Basic Link Services
The basic link services are shown in the following table:
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
Class 1 only)
RMC Remove Connection Rejected
Class 1 only)
A.2. Pass-Through Link Services
As specified in Section 7, the link service requests of Table 10 and
the associated ACC response frames MUST be passed to the receiving
N_PORT without altering the payload.
ADVC Advise Credit
CSR Clock Synchronization Request
CSU Clock Synchronization Update
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
FDACT Fabric Deactivate Alias_ID
FDISC Discover F_Port Service
FLOGI F_Port Login
GAID Get Alias_ID
LCLM Login Control List Management
LINIT Loop Initialize
LIRR Link Incident Record
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
PRLI Process Login
PRLO Process Logout
QoSR Quality of Service Request
RCS Read Connection Status
RLIR Registered Link Incident
RNC Report Node Capability
RNFT Report Node FC-4 Types
RNID Request Node Identification
RPL Read Port List
RPS Read Port Status Block
RPSC Report Port Speed
RSCN Registered State Change
RTV Read Timeout Value
RVCS Read Virtual Circuit Status
SBRP Set Bit-Error Reporting
SCN State Change Notification
SCR State Change Registration
TPLS Test Process Login State
Table 10. Pass-Through Link Services
A.3. Special Link Services
The extended and FC-4 link services of Table 11 are processed by an
iFCP implementation as described in the sections referenced in the
Name Description Section
---- ----------- -------
ABTX Abort Exchange 184.108.40.206
ADISC Discover Address 220.127.116.11
ADISC Discover Address Accept 18.104.22.168
FARP- Fibre Channel Address 22.214.171.124
REPLY Resolution Protocol
FARP- Fibre Channel Address 126.96.36.199
REQ Resolution Protocol
LOGO N_PORT Logout 188.8.131.52
PLOGI Port Login 184.108.40.206
REC Read Exchange Concise 220.127.116.11
REC ACC Read Exchange Concise 18.104.22.168
FCP REC FCP Read Exchange 22.214.171.124.1
Concise (see [FCP-2])
FCP REC FCP Read Exchange 126.96.36.199.2
ACC Concise Accept (see
RES Read Exchange Status 188.8.131.52
RES ACC Read Exchange Status 184.108.40.206
RLS Read Link Error Status 220.127.116.11
RRQ Reinstate Recovery 18.104.22.168
RSI Request Sequence 22.214.171.124
RSS Read Sequence Status 126.96.36.199
SRL Scan Remote Loop 188.8.131.52
TPRLO Third Party Process 184.108.40.206
TPRLO Third Party Process 220.127.116.11
ACC Logout Accept
Table 11. Special Link Services
Appendix B. Supporting the Fibre Channel Loop Topology
A loop topology may be optionally supported by a gateway
implementation in one of the following ways:
a) By implementing the FL_PORT public loop interface specified in
b) By emulating the private loop environment specified in [FC-AL2].
Private loop emulation allows the attachment of fibre channel devices
that do not support fabrics or public loops. The gateway presents
such devices to the fabric as though they were fabric-attached.
Conversely, the gateway presents devices on the fabric, whether they
are locally or remotely attached, as though they were connected to
the private loop.
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.
B.1. Remote Control of a Public Loop
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 through which the public loop may be
The LFA and FL_PORT address identifier both represent an N_PORT that
services remote loop management requests contained in the LINIT and
SRL extended link service messages. To support these messages, the
gateway MUST allocate an NL_PORT alias so that the corresponding
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.
The authors are indebted to those who contributed material and who
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).
Comments should be sent to the ips mailing list (firstname.lastname@example.org) or
to the authors.
7553 Morevern Circle
San Jose, CA 95135
4555 Great America Pkwy
Santa Clara, CA 95054
600 Technology Park Drive
Billerica, MA 01821 USA
TROIKA Networks, Inc.
2555 Townsgate Road, Suite 105
Westlake Village, CA 91361
Adaptec (UK) Ltd.
4th Floor, Howard House
Queens Ave, UK. BS8 1SD
Phone: +44 (0)117 930 9600
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.
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
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-
Funding for the RFC Editor function is currently provided by the