Internet DRAFT - draft-desanti-imss-ipv4-over-fibre-channel
draft-desanti-imss-ipv4-over-fibre-channel
Internet Draft C. DeSanti
draft-desanti-imss-ipv4-over-fibre-channel-00.txt Cisco Systems
Expires: April 2005 C. Carlson
QLogic Corporation
October 2004
Transmission of IPv4 and ARP Packets over Fibre Channel
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a way of encapsulating IPv4 and ARP packets
over Fibre Channel, and a mechanism to perform IPv4 address
resolution over Fibre Channel networks.
DeSanti & Carlson Expires April 2005 [Page 1]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
Table Of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel. . . . . . . . . . . . . . . . . . . 3
2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Identifiers and Login . . . . . . . . . . . . . . . . . . . . 4
2.3 FC Levels and Frame Format. . . . . . . . . . . . . . . . . . 5
2.4 Sequences and Exchanges . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Capable Nx_Ports . . . . . . . . . . . . . . . . . . . . 6
4. IPv4 and ARP Encapsulation. . . . . . . . . . . . . . . . . . 6
4.1 FC Sequence Format for IPv4 Packets . . . . . . . . . . . . . 6
4.2 FC Sequence Format for ARP Packets. . . . . . . . . . . . . . 8
4.3 FC Classes of Service . . . . . . . . . . . . . . . . . . . . 8
4.4 FC Header Code Points . . . . . . . . . . . . . . . . . . . . 9
4.5 FC Network_Header . . . . . . . . . . . . . . . . . . . . . . 10
4.6 LLC/SNAP Header . . . . . . . . . . . . . . . . . . . . . . . 10
4.7 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 11
4.8 Maximum Transfer Unit . . . . . . . . . . . . . . . . . . . . 11
5. ARP Packet Format . . . . . . . . . . . . . . . . . . . . . . 11
6. Address Mapping for Unicast . . . . . . . . . . . . . . . . . 13
7. Address Mapping for Multicast . . . . . . . . . . . . . . . . 14
8. Sequence Management . . . . . . . . . . . . . . . . . . . . . 15
9. Exchange Management . . . . . . . . . . . . . . . . . . . . . 15
10. Interoperability with [RFC-2625]. . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
14. Normative References. . . . . . . . . . . . . . . . . . . . . 17
15. Informative References. . . . . . . . . . . . . . . . . . . . 18
16. Authors' Address. . . . . . . . . . . . . . . . . . . . . . . 18
A. Transmission of a Broadcast FC Sequence over FC Topologies. . 19
B. Validation of the <N_Port_Name, N_Port_ID> mapping. . . . . . 20
C. Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . 21
D. Changes from [RFC-2625] . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Fibre Channel (FC) is a high speed serial interface technology that
supports several Upper Layer Protocols including Small Computer
System Interface (SCSI) and IP.
[RFC-2625] defined how to encapsulate IPv4 and ARP packets over Fibre
Channel for a subset of Fibre Channel devices. This specification
enable the support of IPv4 for a broader category of Fibre Channel
devices. In addition, this specification simplifies [RFC-2625] by
removing unused options and clarifying what is currently implemented.
This document is an update to [RFC-2625] and, hence, obsoletes it.
DeSanti & Carlson Expires April 2005 [Page 2]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
Specific limitations that this document aims to resolve are:
- N_Port_Name format restriction. [RFC-2625] restricts the use of
IPv4 to Fibre Channel devices having format 0x1 N_Port_Name, but
many current implementations use other N_Port_Name formats.
- Use of FARP. [RFC-2625] requires the support of FARP-REPLY to map
N_Port_Names to N_Port_IDs, but many current implementations use
other methods, such as the Fibre Channel Name Server.
- Missing support for IPv4 multicast. [RFC-2625] does not specify
how to transmit IPv4 packets with a multicast destination address
over Fibre Channel.
Warning to readers familiar with Fibre Channel: both Fibre Channel
and IETF standards use the same byte transmission order. However, the
bit numbering is different. See Appendix C for guidance.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
2. Summary of Fibre Channel
2.1. Overview
Fibre Channel (FC) is a gigabit speed network technology primarily
used for Storage Networking. Fibre Channel is standardized in the T11
Technical Committee of the InterNational Committee for Information
Technology Standards (INCITS), an American National Standard
Institute (ANSI) accredited standards committee.
Fibre Channel devices are called Nodes. Each Node has one or more
Ports that connect to Ports of other devices. Fibre Channel may be
implemented using any combination of the following three topologies:
- a point-to-point link between two Ports;
- a set of Ports interconnected by a switching network called a
Fabric, as defined in [FC-FS];
- a set of Ports interconnected with a loop topology, as defined in
[FC-AL-2].
A Node Port is more precisely called an N_Port. A Node Port that is
capable of operating in a loop topology using the loop specific
protocols is designated as an NL_Port. The term Nx_Port is used to
generically indicate these two kinds of Node Port.
A Fabric Port is more precisely called an F_Port. A Fabric Port that
is capable of operating in a loop topology using the loop specific
protocols is designated as an FL_Port. The term Fx_Port is used to
generically indicate these two kinds of Fabric Port.
DeSanti & Carlson Expires April 2005 [Page 3]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
A Fibre Channel network, built with any combination of the FC
topologies described above, is a multiaccess network with broadcast
capabilities.
From an IPv4 point of view, a Fibre Channel network is an IPv4 Local
Network. IPv4-capable Nx_Ports are what [IPv4] calls Local Network
Interfaces.
2.2. Identifiers and Login
Fibre Channel entities are identified by permanent 64 bit long
Name_Identifiers. [FC-FS] defines several formats of
Name_Identifiers. The value of the the most significant four bits
defines the format of a Name_Identifier. These names are referred to
in a more precise manner as follows:
- an Nx_Port's Name_Identifier is called N_Port_Name;
- an Fx_Port's Name_Identifier is called F_Port_Name;
- a Node's Name_Identifier is called Node_Name;
- a Fabric's Name_Identifier is called Fabric_Name.
An Nx_Port connected to a Fibre Channel network is associated with
two identifiers, its permanent N_Port_Name and a volatile 24 bit
address called N_Port_ID. The N_Port_Name is used to identify the
Nx_Port, while the N_Port_ID is used for communications among
Nx_Ports.
Each Nx_Port acquires an N_Port_ID from the Fabric by performing a
process called Fabric Login or FLOGI. The FLOGI process is used also
to negotiate several communications parameters between the Nx_Port
and the Fabric, such as the receive data field size, which determines
the maximum size of the Fibre Channel frames that may be transferred
between the Nx_Port and the Fabric.
Before effective communication may take place between two Nx_Ports,
they must complete a process called Port Login or PLOGI. The PLOGI
process provides each Nx_Port with the other Nx_Port's N_Port_Name,
and negotiates several communication parameters, such as the receive
data field size, which determines the maximum size of the Fibre
Channel frames that may be transferred between the two Nx_Ports.
Both Fabric Login and Port Login may be explicit, i.e., performed
using specific FC control messages (called Extended Link Services or
ELS), or implicit, in which the parameters are specified by
configuration or other methods.
DeSanti & Carlson Expires April 2005 [Page 4]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
2.3. FC Levels and Frame Format
[FC-FS] describes the Fibre Channel protocol using 5 different
levels. The FC-2 and FC-4 levels are relevant for this specification.
The FC-2 level defines the FC frame format, the transport services,
and control functions necessary for information transfer. The FC-4
level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The
Fibre Channel frame format is shown in figure 1.
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
The Start of Frame (SOF) and End of Frame (EOF) are special FC
transmission words that act as frame delimiters. The CRC is 4 octets
long and uses the same 32-bit polynomial used in Ethernet.
The FC Header is 24 octets long and contains several fields
associated with the identification and control of the Data Field.
The Data Field is of variable size, ranging from 0 to 2112 octets,
and includes the user data in the Frame Payload field, and Optional
Headers. The currently defined Optional Headers are:
- ESP_Header;
- Network_Header;
- Association_Header;
- Device_Header.
The value of the SOF field determines the FC Class of service
associated with the frame. Five Classes of service are specified in
[FC-FS]. They are distinguished primarily by the method of flow
control between the communicating Nx_Ports and by the level of data
integrity provided. A given Fabric or Nx_Port may support one or more
of the following Classes of service:
- Class 1: Dedicated physical connection with delivery confirmation;
- Class 2: Frame multiplexed service with delivery confirmation;
- Class 3: Datagram service;
- Class 4: Fractional bandwidth;
- Class 6: Reliable multicast via dedicated connections.
Class 3 and 2 are used for storage networking applications; Class 1
and 6 are used for specialized applications in avionics. Class 3 is
recommended for IPv4 (see section 4.3).
DeSanti & Carlson Expires April 2005 [Page 5]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
2.4. Sequences and Exchanges
An application level payload such as IPv4 is called an Information
Unit at the FC-4 level of Fibre Channel. Each FC-4 Information Unit
is mapped to an FC Sequence by the FC-2 level. An FC Sequence
consists of one or more FC frames related by the value of the
Sequence_ID (SEQ_ID) field of the FC Header.
The maximum data that may be carried by an FC frame is 2112 octets.
The maximum usable frame size depends on the Fabric and Nx_Port
implementations and is negotiated during the Login process. Whenever
an Information Unit to be transmitted exceeds this value, the FC-2
level segments it into multiple FC frames, sent as a single Sequence.
The receiving Nx_Port reassembles the Sequence of frames and delivers
a reassembled Information Unit to the FC-4 level. The Sequence Count
(SEQ_CNT) field of the FC Header may be used to ensure frame
ordering.
Multiple Sequences may be related together as belonging to the same
FC Exchange. The Exchange is a mechanism used by two Nx_Ports to
identify and manage an operation between them. The Exchange is opened
when the operation is started between the two Nx_Ports, and closed
when the operation ends. FC frames belonging to the same Exchange are
related by the value of the Exchange_ID fields in the FC Header. An
Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID)
uniquely identify the Exchange between a pair of Nx_Port.
3. IPv4 Capable Nx_Ports
This specification requires an IPv4 capable Nx_Port to have the
following properties:
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
0xD, 0xE, 0xF [FC-FS];
- It MUST support Class 3;
- It MUST support continuously increasing SEQ_CNT [FC-FS];
- It SHOULD support a receive data field size for Device_Data FC
frames of at least 1024 octets.
4. IPv4 and ARP Encapsulation
4.1. FC Sequence Format for IPv4 Packets
An IPv4 packet is mapped to an Information Unit at the FC-4 level of
Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2
level. An FC Information Unit containing an IPv4 packet MUST carry
DeSanti & Carlson Expires April 2005 [Page 6]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC],
resulting in the FC Information Unit format shown in figure 2.
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv4 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv4 Packet
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames
composing the FC Sequence. [AH] or [ESP] may be used to provide
security at the IPv4 layer. Other types of FC Optional Header MUST
NOT be used in an IPv4 FC Sequence.
Typically, a Sequence consists of more than one frame. Only the first
frame of the Sequence MUST include the FC Network_Header and the
LLC/SNAP header. The other frames MUST NOT include them, as shown in
figure 3.
First Frame of an IPv4 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv4 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv4 FC Sequence
+-----------+-----------------//--------------------+
| FC Header | Additional chunk of the IPv4 Packet |
+-----------+----------------//---------------------+
Fig. 3: Optional Headers in an IPv4 FC Sequence
DeSanti & Carlson Expires April 2005 [Page 7]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
4.2. FC Sequence Format for ARP Packets
An ARP packet is mapped to an Information Unit at the FC-4 level of
Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2
level. An FC Information Unit containing an ARP packet MUST carry the
FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC],
resulting to the FC Information Unit format shown in figure 4.
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ ARP Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Information Unit Mapping an ARP Packet
Given the limited size of an ARP packet (see section 5), an FC
Sequence carrying an ARP packet MUST be mapped to a single FC frame,
that MUST include the FC Network_Header and the LLC/SNAP header.
The FC ESP_Header [FC-FS] MAY be used to secure an ARP FC frame.
Other types of FC Optional Header MUST NOT be used in an ARP FC
frame.
4.3. FC Classes of Service
This specification uses FC Class 3. ARP packets MUST be encapsulated
in Class 3 FC frames. IPv4 packets SHOULD use Class 3 as well.
DeSanti & Carlson Expires April 2005 [Page 8]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
4.4. FC Header Code Points
The fields of the Fibre Channel Header are shown in figure 5. The
D_ID and S_ID fields contain respectively the destination N_Port_ID
and the source N_Port_ID.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 5: FC Header Format
To encapsulate IPv4 over Fibre Channel the following code points
apply. When a single value is listed without further qualification
that value MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv4
Sequence, 0x00 for the following FC frames. If the FC ESP_Header
is used, then 0x60 for the first FC frame of an IPv4 Sequence,
0x40 for the following FC frames;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 8, section 9,
and [FC-FS] for additional requirements;
- Parameter: if Relative Offset [FC-FS] is not used, the content of
this field MUST be ignored by the receiver, and SHOULD be set to
zero by the sender. If Relative Offset is used, see [FC-FS].
To encapsulate ARP over Fibre Channel the following code points
apply. When a single value is listed without further qualification
that value MUST be used:
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information
Category [FC-FS]);
- TYPE: 0x05 (IP over Fibre Channel);
DeSanti & Carlson Expires April 2005 [Page 9]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
- CS_CTL/Prio: 0x00 is the default, see [FC-FS] for other values;
- DF_CTL: 0x20 (Network_Header). If the FC ESP_Header is used, then
0x60;
- F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 8, section 9,
and [FC-FS] for additional requirements;
- Parameter: if Relative Offset [FC-FS] is not used, the content of
this field MUST be ignored by the receiver, and SHOULD be set to
zero by the sender. If Relative Offset is used, see [FC-FS].
4.5. FC Network_Header
The fields of the FC Network_Header are shown in figure 6. For use
with IPv4 and ARP the N_Port_Names formats MUST be one of 0x1, 0x2,
0x5, 0xC, 0xD, 0xE, 0xF [FC-FS].
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 6: FC Network_Header Format
4.6. LLC/SNAP Header
The fields of the LLC/SNAP Header [IEEE-LLC] are shown in figure 7.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 7: LLC/SNAP Header Format
DeSanti & Carlson Expires April 2005 [Page 10]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
To encapsulate IPv4 over Fibre Channel the following code points MUST
be used:
- DSAP: 0xAA
- SSAP: 0xAA
- CTRL: 0x03
- OUI: 0x000000
- PID: 0x0800
To encapsulate ARP over Fibre Channel the following code points MUST
be used:
- DSAP: 0xAA
- SSAP: 0xAA
- CTRL: 0x03
- OUI: 0x000000
- PID: 0x0806
4.7. Bit and Byte Ordering
IPv4 and ARP packets are mapped to the FC-4 level using the big-
endian byte ordering that corresponds to the standard network byte
order or canonical form.
4.8. Maximum Transfer Unit
The default MTU size for IPv4 packets over Fibre Channel is 65280
octets. This size may be reduced by manual configuration of each
Nx_Port or by the Path MTU Discovery technique [PMTU], if supported.
Large IPv4 packets are mapped to a Sequence of FC frames (see section
2.4).
5. ARP Packet Format
The Address Resolution Protocol defined in [ARP] was designed to be a
general purpose protocol, and to work with many network technologies,
and with many upper layer protocols.
[RFC-2625] chose to use for Fibre Channel the same ARP packet format
used for Ethernet networks. By doing that, [RFC-2625] restricted the
use of IPv4 to Nx_Ports having N_Port_Name format 0x1. While this may
have been a reasonable choice at that time, today there are Nx_Ports
with N_Port_Name format other than 0x1 in widespread use.
This specification accomodates Nx_Ports with N_Port_Names of format
different than 0x1 by defining a Fibre Channel specific version of
DeSanti & Carlson Expires April 2005 [Page 11]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
the ARP protocol, carrying both N_Port_Name and N_Port_ID as ARP HW
address.
IANA has registered the number 18 to identify Fibre Channel as ARP HW
type. The FC ARP packet format is shown in figure 8. The length of
the FC ARP packet is 40 octets.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Type = 0x0012 | Protocol = 0x0800 |
+---------------+---------------+---------------+---------------+
| HW Len = 12 | Proto Len = 4 | Opcode |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Sender |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Sender |
+---------------+---------------+---------------+---------------+
| |
+- -+
| HW Address of Target |
+- -+
| |
+---------------+---------------+---------------+---------------+
| Protocol Address of Target |
+---------------+---------------+---------------+---------------+
Fig. 8: FC ARP Packet Format
The following code points MUST be used with FC ARP:
- HW Type: 0x0012 (Fibre Channel);
- Protocol: 0x0800 (IPv4);
- HW Len: 12 (Length in octets of the HW Address);
- Proto Len: 4 (Length in octets of the Protocol Address);
- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply;
- HW Address of Sender: the N_Port_Name and N_Port_ID of the
Requester in an ARP Request, or those of the Responder in an ARP
Reply;
- Protocol Address of Sender: the IPv4 address of the Requester in
an ARP Request, or that of the Responder in an ARP Reply;
- HW Address of Target: set to zero in an ARP Request, and to the
N_Port_Name and N_Port_ID of the Requester in an ARP Reply;
- Protocol Address of Target: the IPv4 address of the Responder in
an ARP Request, or that of the Requester in an ARP Reply.
DeSanti & Carlson Expires April 2005 [Page 12]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
The format of the HW address for Fibre Channel ARP is shown in figure
9.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Fig. 9: FC ARP HW Address Format
Reserved fields MUST be set to zero when transmitting, and MUST be
ignored when receiving.
6. Address Mapping for Unicast
An Nx_Port has two kinds of Fibre Channel addresses:
- a non-volatile 64-bit address, called N_Port_Name;
- a volatile 24-bit address, called N_Port_ID.
The N_Port_Name is used to uniquely identify the Nx_Port, while the
N_Port_ID is used to route frames to the Nx_Port. Both FC addresses
are required to resolve an IPv4 unicast address. The fact that the
N_Port_ID is volatile implies that an Nx_Port MUST validate the
mapping between its N_Port_Name and N_Port_ID when certain Fibre
Channel events occur (see Appendix B).
The procedure for mapping IPv4 unicast addresses into Fibre Channel
link-layer addresses uses the FC ARP protocol, as specified in
section 5 and [ARP]. A source Nx_Port that has to send IPv4 packets
to a destination Nx_Port, known by its IPv4 address, MUST perform the
following steps:
a) The source Nx_Port should first consult its local mapping tables
for a mapping <destination IPv4 address, N_Port_Name, N_Port_ID>.
b) If such a mapping is found, and a valid Port Login is in place
with the destination Nx_Port, then the source Nx_Port sends the
IPv4 packets to the destination Nx_Port using the retrieved
N_Port_ID as D_ID.
c) If such a mapping is not found, or a valid Port Login is not in
place with the destination Nx_Port, then the source Nx_Port MUST
send a broadcast FC ARP Request to its connected FC network.
DeSanti & Carlson Expires April 2005 [Page 13]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
Appendix A specifies how to transmit a Class 3 broadcast FC
Sequence over various Fibre Channel topologies.
d) When a broadcast FC ARP Request is received by the Nx_Port with
the matching IPv4 address, it generates a unicast FC ARP Reply. If
a valid Port Login to the Nx_Port that sent the broadcast FC ARP
Request does not exist, the Nx_Port MUST perform such a Port
Login, and then use it for the unicast reply. The N_Port_ID to
which the Port Login is directed is taken from the N_Port_ID field
of the Sender HW Address field of the received FC ARP packet.
e) If no Nx_Port has the matching IPv4 address, no unicast FC ARP
Reply is returned.
7. Address Mapping for Multicast
By default, all best-effort IPv4 multicast or broadcast packets and
ARP broadcast packets MUST be mapped to FC Sequences addressed to the
broadcast N_Port_ID 0xFFFFFF and sent in FC Class 3. In this case,
the Destination N_Port_Name field of the FC Network_Header MUST be
set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how
to transmit a Class 3 broadcast FC Sequence over various Fibre
Channel topologies.
An Nx_Port supporting IPv4 MUST be able to map a received broadcast
Class 3 Device_Data FC frame to an implicit Port Login context in
order to handle IPv4 multicast or broadcast packets and ARP broadcast
packets. The receive data field size of this implicit Port Login MUST
be the same across all the Nx_Ports connected to the same Fabric,
otherwise FC broadcast transmission does not work. In order to reduce
the need for FC Sequence segmentation, the receive data field size of
this implicit Port Login SHOULD be 1024 octets. This receive data
field size requirement applies to broadcast Device_Data FC frames,
not to ELSs.
Receiving an FC Sequence carrying an IPv4 multicast or broadcast
packet or an ARP broadcast packet triggers some additional processing
by the Nx_Port when that IPv4 or ARP packet requires a unicast reply.
In this case, if a valid Port Login to the Nx_Port that sent the
multicast or broadcast packet does not exist, the Nx_Port MUST
perform such a Port Login, and then use it for the unicast reply. In
the case of ARP messages, the N_Port_ID to which the Port Login is
directed is taken from the N_Port_ID field of the Sender HW Address
field of the received ARP packet.
DeSanti & Carlson Expires April 2005 [Page 14]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
8. Sequence Management
FC Sequences are REQUIRED to be non-streamed. In order to avoid
missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting
IPv4 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each
Exchange MUST start with SEQ_CNT = 0 in the first frame, and every
frame transmitted after that MUST increment the previous SEQ_CNT by
one. Any frames received from the other N_Port in the Exchange shall
have no effect on the transmitted SEQ_CNT.
9. Exchange Management
To transfer IPv4 packets, each Nx_Port MUST have a dedicated Exchange
for sending data to each Nx_Port in the network and a dedicated
Exchange for receiving data from each Nx_Port.
An Exchange Responder is not required to assign RX_IDs. If an RX_ID
of 0xFFFF is assigned, the Exchange Responder is identifying
Exchanges based on S_ID / D_ID / OX_ID only [FC-FS].
When an Exchange is created between two Nx_Ports for unicast IPv4
packets, it remains active while the Nx_Ports are logged in with each
other. Each FC ARP message, FC broadcast and ELS [FC-FS] SHOULD use a
separate short lived Exchange.
For IPv4 and FC ARP, Exchanges MUST NOT transfer Sequence Initiative,
because they are used in a unidirectional mode. The Sequence
Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be
set to zero.
The mechanism for aging or expiring exchanges based on activity,
timeout, or other methods is as specified in [FC-FS].
The Exchange Originator MAY terminate Exchanges by setting the F_CTL
LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator
or Exchange Responder by using the ABTS (Abort Sequence) protocol
[FC-FS]. IPv4 Exchanges SHOULD NOT be terminated by Logout, since
this may terminate active Exchanges on other FC-4s [FC-FS].
10. Interoperability with [RFC-2625]
The IPv4 encapsulation defined in this document, along with Exchange
and Sequence management, are exactly as defined in [RFC-2625].
Implementations following this specification should interoperate
with implementations compliant to [RFC-2625] for IPv4 packet
transmission and reception.
DeSanti & Carlson Expires April 2005 [Page 15]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
The main difference between this document and [RFC-2625] is in the
address resolution procedure. [RFC-2625] uses the Ethernet format of
the ARP protocol, and requires all Nx_Ports to have a format 0x1
N_Port_Name. This specification defines a Fibre Channel format for
the ARP protocol that supports all commonly used N_Port_Names. Also,
this specification does not use FARP [RFC-2625].
A method by which an Nx_Port implementing this specification, and not
using format 0x1 N_Port_Name, may interoperate with an [RFC-2625]
implementation is by manually configuring the mapping <destination
IPv4 address, N_Port_Name, N_Port_ID> on the involved Nx_Ports.
Through this manual configuration, the ARP protocol does not need to
be performed. However, issues may still arise in the IPv4 packet
communication if the [RFC-2625] implementation strictly enforces the
requirement for Nx_Ports to use N_Port_Names of format 0x1.
An Nx_Port following this specification, and having a format 0x1
N_Port_Name, MAY interoperate with an [RFC-2625] implementation by
using the manual configuration approach described above, or by
performing the IPv4 address resolution as described below. Each
implementation MUST implement the behavior described below, but the
use of this behavior MUST be administratively configurable.
- The Nx_Port MUST send, when IPv4 address resolution is attempted,
two ARP Requests separated by a short time interval (e.g., less
than one second), the first one according to the FC ARP format and
the second one according to the Ethernet ARP format. The Nx_Port
should then process the first ARP Reply received. If only an
Ethernet ARP Reply is received, it provides the N_Port_Name of the
Nx_Port having the destination IPv4 address. The N_Port_ID
associated with the N_Port_Name received in an Ethernet ARP Reply
may be retrieved from the S_ID field of the received ARP Reply, or
by querying the Fibre Channel Name Server.
- The Nx_Port MUST respond to a received Ethernet ARP Request with
an Ethernet ARP Reply.
- The Nx_Port MAY respond to FARP Requests [RFC-2625].
The reception of a particular format of ARP message does not imply
that the sending NX_Port will continue to use the same format later.
11. Security Considerations
IPv4 and ARP do not introduce any additional security concerns beyond
those that already exist within the Fibre Channel protocols. Zoning
techniques based on FC Name Server masking (soft zoning) do not work
with IPv4, because IPv4 over Fibre Channel does not use the FC Name
Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames
composing FC Sequences carrying IPv4 and ARP packets. All the
DeSanti & Carlson Expires April 2005 [Page 16]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
techniques defined to secure IPv4 traffic may be used in a Fibre
Channel Environment.
12. IANA Considerations
The directory of ARP parameters should reference this document, when
published, for hardware type 18.
13. Acknowledgments
The authors would like to acknowledge the ANSI INCITS T11.3 Task
Group members who reviewed this document.
14. Normative References
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and
Signaling (FC-FS)".
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2
(FC-AL-2)".
[IPv4] J. Postel, "Internet Protocol", STD-5, RFC 791,
September 1981.
[ARP] D. Plummer, "An Ethernet Address Resolution Protocol -or-
Converting Network Addresses to 48-bit Ethernet Address
for Transmission on Ethernet Hardware", STD-37, RFC 826,
November 1982.
[RFC-2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[PMTU] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture".
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
DeSanti & Carlson Expires April 2005 [Page 17]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
15. Informative References
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
16. Authors' Address
Claudio DeSanti
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
Craig W. Carlson
QLogic Corporation
6321 Bury Drive
Eden Prairie, MN 55346
USA
Phone: +1 952 932-4064
Email: craig.carlson@qlogic.com
DeSanti & Carlson Expires April 2005 [Page 18]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
A. Transmission of a Broadcast FC Sequence over FC Topologies
(Informative)
A.1. Point-to-Point Topology
No particular mechanisms are required for this case. The Nx_Port
connected at the other side of the cable receives the broadcast FC
Sequence having D_ID 0xFFFFFF.
A.2. Private Loop Topology
An NL_Port attached to a private loop MUST transmit a Class 3
broadcast FC Sequence by using the OPN(fr) primitive signal
[FC-AL-2].
a) The source NL_Port first sends an Open Broadcast Replicate
(OPN(fr)) primitive signal, forcing all the NL_Ports in the loop
(except itself) to replicate the frames that they receive while
examining the FC Header's D_ID field.
b) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
c) The source NL_Port then sends the Class 3 broadcast FC Sequence
having D_ID 0xFFFFFF.
A.3. Public Loop Topology
An NL_Port attached to a public loop MUST NOT use the OPN(fr)
primitive signal. Rather, it MUST send the Class 3 broadcast FC
Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00
[FC-AL-2].
The Fabric propagates the broadcast to all other FC_Ports [FC-FS],
including the FL_Port which the broadcast arrived on. This includes
all F_Ports, and other FL_Ports.
Each FL_Port propagates the broadcast by using the primitive signal
OPN(fr), in order to prepare the loop to receive the broadcast
sequence.
A.4. Fabric Topology
An N_Port connected to an F_Port MUST transmit the Class 3 broadcast
FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates
the broadcast to all other FC_Ports [FC-FS].
DeSanti & Carlson Expires April 2005 [Page 19]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
B. Validation of the <N_Port_Name, N_Port_ID> mapping
(Informative)
B.1. Overview
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid
before use.
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may
change, as well as the N_Port_IDs of all other Nx_Ports that have
previously performed Port Login with this Nx_Port. Because of this,
address validation is required after a LIP in a loop topology
[FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS].
N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus
address validation is not required in this case.
B.2. FC Layer Address Validation in a Point-to-Point Topology
No validation is required after LR. In a point-to-point topology,
NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS
each N_Port must again perform a Port Login [FC-FS].
B.3. FC Layer Address Validation in a Private Loop Topology
After a LIP [FC-AL-2], an NL_Port must not transmit any data to
another NL_Port until the address of the other port has been
validated. The validation consists of completing either ADISC or
PDISC [FC-FS].
For a requester, this specification prohibits PDISC and requires
ADISC. As a responder, an implementation may need to respond to both
ADISC and PDISC for compatibility with other FC specifications.
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a
logged remote NL_Port exactly match the values prior to the LIP, then
any active Exchange with that NL_Port may continue.
If any of the three FC addresses has changed, then the remote NL_Port
must be logged out.
If an NL_Port's N_Port_ID changes after a LIP, then all active logged
in NL_Ports must be logged out.
DeSanti & Carlson Expires April 2005 [Page 20]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
B.4. FC Layer Address Validation in a Public Loop Topology
A FAN ELS may be sent by the Fabric to all known previously logged in
NL_Ports following an initialization event. Therefore, after a LIP
[FC-AL-2], NL_Ports may wait for this notification to arrive, or they
may perform an FLOGI.
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI
response exactly match the values before the LIP and if the AL_PA
[FC-AL-2] obtained by the NL_Port is the same as the one before the
LIP, then the port may resume all Exchanges. If not, then FLOGI must
be performed with the Fabric and all logged in Nx_Ports must be
logged out.
A public loop NL_Port must perform the private loop validation as
specified in section B.3 to any NL_Port on the local loop that has an
N_Port_ID of the form 0x00-00-XX.
B.5. FC Layer Address Validation in a Fabric Topology
No validation is required after LR (link reset).
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the
N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same
as before the NOS/OLS, then the N_Port may resume all Exchanges. If
not, all logged in Nx_Ports must be logged out [FC-FS].
C. Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit numbering is different.
Fibre Channel bit numbering can be observed if the data structure
heading shown in figure 10 is cut and pasted at the top of the
figures present in this document.
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 10: Fibre Channel Bit Numbering
DeSanti & Carlson Expires April 2005 [Page 21]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
D. Changes from [RFC-2625]
- Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF
are supported, in addition to format 0x1;
- An IPv4 capable Nx_Port MUST support Class 3;
- An IPv4 capable Nx_Port MUST support continuously increasing
SEQ_CNT [FC-FS];
- An IPv4 capable Nx_Port SHOULD support a receive data field size
for Device_Data FC frames of at least 1024 octets;
- The FC ESP_Header MAY be used;
- FC Classes of services other than 3 are not supported;
- A new FC ARP format is defined;
- Support for FARP is removed, because it becomes useless with the
new FC ARP and its usage creates interoperability issues, given
that it is not uniformely implemented.
DeSanti & Carlson Expires April 2005 [Page 22]
INTERNET DRAFT IPv4 and ARP over Fibre Channel October 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
DeSanti & Carlson Expires April 2005 [Page 23]
