[要約] RFC 2625は、Fibre Channel上でのIPとARPの使用に関する標準を定義しています。このRFCの目的は、Fibre Channelネットワーク上でのIP通信とARPプロトコルの適切な実装を促進することです。
Network Working Group M. Rajagopal
Request for Comments: 2625 R. Bhagwat
Category: Standards Track W. Rickard
Gadzoox Networks
June 1999
IP and ARP over Fibre Channel
ファイバーチャネル上のIPおよびARP
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards [3] do not adequately specify how IP packets may be transported over FC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.
Fiber Channel（FC）は、Small Computer System Interface（SCSI）やインターネットプロトコル（IP）を含むいくつかの高層プロトコルをサポートする高速シリアルインターフェイステクノロジーです。これまで、SCSIはFCよりも広く使用されている唯一のプロトコルでした。既存のFC標準[3]は、FCを介してIPパケットをどのように輸送するか、およびIPアドレスがFCアドレスに解決する方法を適切に指定していません。このドキュメントの目的は、ファイバーチャネルを介したIPおよびアドレス解像度プロトコル（ARP）をカプセル化する方法を指定し、IPアドレス解像度のメカニズムを説明することです。
Table of Contents
目次
1. Introduction ............................................... 3
2. Problem Statement .......................................... 5
3. IP and ARP Encapsulation ................................... 5
3.1 FC Frame Format ........................................ 5
3.2 MTU .................................................... 7
3.2.1 IP MTU ........................................... 7
3.2.2 Maximally Minimum IPv4 packet .................... 8
3.2.3 ARP MTU .......................................... 8
3.2.4 FC Data Field containing FARP Packet ............. 9
3.3 FC Port and Node Network Addresses ..................... 9
3.4 FC Sequence Payload Format ............................. 10
3.5 Bit and Byte Ordering .................................. 12
4. ARP ........................................................ 12
4.1 Address Resolution .................................... 12
4.2 ARP Packet Format ...................................... 13
4.3 ARP Layer Mapping and Operation ........................ 15
4.4 ARP Broadcast in a Point-to-Point Topology ............. 16
4.5 ARP Broadcast in a Private Loop Topology ............... 16
4.6 ARP Broadcast in a Public Loop Topology ................ 16
4.7 ARP Operation in a Fabric Topology ..................... 17
5. FARP ....................................................... 18
5.1 Scope .................................................. 18
5.2 FARP Overview .......................................... 18
5.3 FARP Command Format .................................... 20
5.4 Match Address Code Points .............................. 22
5.5 Responder Flags ........................................ 23
5.6 FARP Support Requirements .............................. 24
6. Exchange Management ........................................ 25
6.1 Exchange Origination ................................... 25
6.2 Exchange Termination ................................... 25
7. Summary of Supported Features .............................. 25
7.1 FC-4 Header ............................................ 25
7.2 R_CTL .................................................. 26
7.3 F_CTL .................................................. 27
7.4 Sequences .............................................. 28
7.5 Exchanges .............................................. 29
7.6 ARP and InARP ......................................... 30
7.7 Extended Link Services (ELS) ........................... 31
7.8 Login Parameters ....................................... 31
7.8.1 Common Service Parameters - FLOGI ............... 32
7.8.2 Common Services Parameters - PLOGI ............... 32
7.8.3 Class Service Parameters - PLOGI ................. 32
8. Security Considerations .................................... 32
8.1 IP and ARP Related ..................................... 32
8.2 FC Related ............................................. 32
9. Acknowledgements ........................................... 33
10. References ................................................ 33
11. Authors' Addresses ........................................ 35
Appendix A: Additional Matching Mechanisms in FARP ............ 36
Appendix B: InARP ............................................. 40
B.1 General Discussion ..................................... 40
B.2 InARP Protocol Operation ............................... 40
B.3 InARP Packet Format .................................... 40
B.4 InARP Support Requirements ............................. 41
Appendix C: Some Informal Mechanisms for FC Layer Mappings .... 42
C.1 Login on cached Mapping Information .................... 42
C.2 Login on ARP parsing ................................... 42
C.3 Login to Everyone ...................................... 43
C.4 Static Table ........................................... 43
Appendix D: FC Layer Address Validation........................ 44
D.1 General Discussion ..................................... 44
D.2 FC Layer Address Validation in a Point-to-Point Topology 45
D.3 FC Layer Address Validation in a Private Loop Topology . 45
D.4 FC Layer Address Validation in a Public Loop Topology .. 45
D.5 FC layer Address Validation in a Fabric Topology ....... 46
Appendix E: Fibre channel Overview ............................ 47
E.1 Brief Tutorial ......................................... 47
E.2 Exchange, Information Unit, Sequence, and Frame ........ 48
E.3 Fibre Channel Header Fields ............................ 49
E.4 Code Points for FC Frame ............................... 52
E.4.1 Code Points with IP and ARP Packet .............. 52
E.4.2 Code Points with FARP Command ................... 54
Appendix F: Fibre Channel Protocol Considerations.............. 58
F.1 Reliability in Class 3 ................................. 58
F.2 Continuously Increasing SEQ_CNT ........................ 58
Appendix G: Acronyms and Glossary of FC Terms ................. 60
Full Copyright Statement ...................................... 63
Fibre Channel (FC) is a gigabit speed networking technology primarily used for Storage Area Networking (SAN). FC is standardized under American National Standard for Information Systems of the National Committee for Information Technology Standards (NCITS) and has specified a number of documents describing its protocols, operations, and services.
ファイバーチャネル（FC）は、主にストレージエリアネットワーキング（SAN）に使用されるギガビットスピードネットワーキングテクノロジーです。FCは、全国情報技術標準委員会（NCITS）の情報システムのためのアメリカ国家標準の下で標準化されており、そのプロトコル、運用、およびサービスを説明する多くの文書を指定しています。
Need:
必要：
Currently, Fibre Channel is predominantly used for communication between storage devices and servers using the SCSI protocol, with most of the servers still communicating with each other over LANs. Although, there exists a Fibre Channel Standard [3] that has architecturally defined support for IP encapsulation and address resolution, it is inadequately specified. ([3] prohibits broadcasts, thus loops are not covered; [10] has no support for Class 3).
現在、ファイバーチャネルは主にSCSIプロトコルを使用してストレージデバイスとサーバー間の通信に使用されており、ほとんどのサーバーはLANを介して互いに通信しています。IPカプセル化とアドレス解像度のアーキテクタントに定義されたサポートを備えたファイバーチャネル標準[3]が存在しますが、それは不十分に指定されています。（[3]は放送を禁止するため、ループはカバーされません。[10]はクラス3をサポートしていません）。
This has lead to a nonstandard way of using IP over FC in the past. Once such a standard method is completely specified, servers can directly communicate with each other using IP over FC, possibly boosting performance in Server host-to-host communications. This technique will be especially useful in a Clustering Application.
これは、過去にFCを介してIPを使用する標準以外の方法につながりました。このような標準メソッドが完全に指定されると、サーバーはFCを介してIPを使用して互いに直接通信し、サーバーホストツーホスト通信のパフォーマンスを向上させる可能性があります。この手法は、クラスタリングアプリケーションで特に役立ちます。
Objective and Scope:
目的と範囲：
The major objective of this specification is to promote interoperable implementations of IPv4 over FC. This specification describes a method for encapsulating IPv4 and Address Resolution Protocol (ARP) packets over FC. This specification accommodates any FC topology (loop, fabric, or point-to-point) and any FC class of service (1, 2 or 3). This specification also describes a FC Address Resolution Protocol(FARP) for associating World Wide Port Names (MAC addresses) and FC Port identifiers.
この仕様の主な目的は、FCを介したIPv4の相互運用可能な実装を促進することです。この仕様では、FCを介したIPv4およびアドレス解像度プロトコル（ARP）パケットをカプセル化する方法について説明します。この仕様には、FCトポロジ（ループ、ファブリック、またはポイントツーポイント）およびFCクラスのサービス（1、2、または3）に対応します。この仕様では、ワールドワイドポート名（MACアドレス）とFCポート識別子を関連付けるためのFCアドレス解像度プロトコル（FARP）についても説明しています。
A secondary objective of this specification is to describe other optional address resolution mechanisms:
この仕様の二次的な目的は、他のオプションのアドレス解決メカニズムを説明することです。
- Other FARP mechanisms that directly build IPv4 address and FC Port Identifier (Port_ID) associations. - Inverse ARP (InARP) that allows learning the IP address of a remote node given its World Wide Port Name (WW_PN) and Port_ID.
- IPv4アドレスとFCポート識別子（PORT_ID）アソシエーションを直接構築するその他のFARPメカニズム。-World Wide Port Name（ww_pn）およびport_idを考慮して、リモートノードのIPアドレスを学習できるようにするInverse arp（inarp）。
"Multicasting" in Fibre Channel is defined as an optional service [11] for FC Classes 3 and 6 only, with no definition for Classes 1 and 2. Currently, there are no vendor implementations of this service for either Class of service. Broadcast service available within Fibre Channel can be used to do multicasting, although less efficiently. Presently, there appears to be no IP applications over Fibre Channel that require support for IP multicasting. This specification therefore does not support IP Multicasting.
ファイバーチャネルの「マルチキャスト」は、FCクラス3および6のみのオプションのサービス[11]として定義されており、クラス1と2の定義はありません。現在、どちらのサービスクラスにもこのサービスのベンダー実装はありません。ファイバーチャネル内で利用可能なブロードキャストサービスは、効率が低いものの、マルチキャストを行うために使用できます。現在、IPマルチキャストのサポートを必要とするファイバーチャネルを介してIPアプリケーションはないようです。したがって、この仕様はIPマルチキャストをサポートしません。
Organization:
組織：
Section 2 states the problem that is solved in this specification. Section 3 describes the techniques used for encapsulating IP and ARP packets in a FC sequence. Section 4 discusses the ARP protocol(IP address to WW_PN). Section 5 discusses the FARP protocol used in FC Layer mappings (WW_PN to Port_ID). Section 6 describes the "Exchange" Management in FC. Section 7 is a summary section and provides a quick reference to FC header settings, FC Link Service Commands, supported features in ARP, FARP, InARP, FC Sequences, FC Exchanges, and FC Login Parameters. Section 8 discusses security. Section 9 acknowledges the technical contributors of this document. Section 10 provides a list of references, and Section 11 provides the authors' addresses.
セクション2では、この仕様で解決された問題を示しています。セクション3では、FCシーケンスでIPパケットとARPパケットをカプセル化するために使用される手法について説明します。セクション4では、ARPプロトコル（ww_pnへのIPアドレス）について説明します。セクション5では、FCレイヤーマッピング（ww_pnからport_id）で使用されるFARPプロトコルについて説明します。セクション6では、FCの「交換」管理について説明します。セクション7は概要セクションであり、FCヘッダー設定、FCリンクサービスコマンド、ARP、FARP、INARP、FCシーケンス、FC交換、FCログインパラメーターのサポート機能を迅速に参照します。セクション8では、セキュリティについて説明します。セクション9では、このドキュメントの技術的な貢献者を認めています。セクション10に参照のリストを示し、セクション11で著者のアドレスを提供します。
Appendix A discusses other optional FARP mechanisms. Appendix B discusses the Inverse ARP protocol(WW_PN to IP address) as an alternate and optional way of building MAC and IP address associations. Appendix C lists some informal mechanisms for FC Layer Mappings. Appendix D provides a discussion on validation of the FC-layer mappings for the different FC topologies. Appendix E provides a brief overview of the FC Protocols and Networks. Appendix F addresses reliability in Class 3 and Sequence Count FC Protocol issues. Appendix G provides a list of acronyms and a glossary of FC Terms used in this specification.
付録Aでは、他のオプションのFARPメカニズムについて説明します。付録Bでは、MACおよびIPアドレスの関連付けを構築する代替およびオプションの方法として、逆ARPプロトコル（ww_pn to IPアドレス）について説明します。付録Cには、FC層マッピングのいくつかの非公式メカニズムがリストされています。付録Dは、さまざまなFCトポロジのFC層マッピングの検証に関する議論を提供します。付録Eでは、FCプロトコルとネットワークの簡単な概要を説明します。付録Fは、クラス3の信頼性とシーケンスカウントFCプロトコルの問題に対処しています。付録Gでは、この仕様で使用されている頭字語のリストとFC用語の用語集を提供します。
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 RFC 2119 [19].
キーワード「必須」、「そうしない」、「必須」、「必要」、「「そうしない」、「そうでない」、「そうではない」、「はらない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [19]に記載されているように解釈されます。
This specification addresses two problems:
この仕様は2つの問題に対処します。
- A format definition and encapsulation mechanism for IPv4 and ARP packets over FC - Mechanisms for Address Resolution
- FC上のIPv4およびARPパケットのフォーマット定義とカプセル化メカニズム - アドレス解決のメカニズム
As noted earlier, the existing FC Standard [3] ([10]) is inadequate to solve the above problems. A solution to both problems was first proposed by the Fibre Channel Association (FCA)[1]. FCA is an industry consortium of FC vendor companies and not a Standards Body. This specification is based on the proposed solution in [1] and builds on it.
前述のように、既存のFC標準[3]（[10]）は、上記の問題を解決するには不十分です。両方の問題の解決策は、Fiber Channel Association（FCA）[1]によって最初に提案されました。FCAは、FCベンダー企業の業界コンソーシアムであり、標準団体ではありません。この仕様は、[1]で提案されたソリューションに基づいており、それに基づいています。
Address Resolution is concerned with resolving IP addresses to WW_PN (MAC address) and WW_PN to FC Port Identifiers (Port_ID). ARP provides a solution to the first resolution problem and FARP the second.
アドレス解決は、ww_pn（Macアドレス）およびww_pnへのIPアドレスの解決に関係しています。ARPは、最初の解像度の問題の解決策を提供し、2番目の解像度の問題を提供します。
An optional FARP mechanism resolves IP address directly to FC Port_IDs. This is useful in some upper layer applications.
オプションのFARPメカニズムは、IPアドレスをFC PORT_IDSに直接解決します。これは、一部の上層層アプリケーションで役立ちます。
InARP is another optional mechanism that resolves WW_PN and Port_ID to an IP address. InARP is useful when a node after performing a PLOGI with another node, knows its WW_PN and Port_ID, but not its IP address.
INARPは、ww_pnとport_idをIPアドレスに解決する別のオプションメカニズムです。INARPは、別のノードでPlogiを実行した後のノードがww_pnとport_idを知っているが、IPアドレスではない場合に役立ちます。
All FC frames have a standard format much like LAN 802.x protocols. (See Appendix E and F). However, the exact size of each frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in Fig. 1.
すべてのFCフレームには、LAN 802.xプロトコルによく似た標準形式があります。（付録Eおよびfを参照）。ただし、各フレームの正確なサイズは、変数フィールドのサイズによって異なります。変数フィールドのサイズは、図1のFCフレーム形式に示すように、0〜2112バイトの範囲です。
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
Fig. 1 FC Frame Format
The Start of Frame (SOF) and End of Frame (EOF) are both 4-bytes long and act as frame delimiters.
フレームの開始（SOF）とフレームの終了（EOF）はどちらも長さ4バイトで、フレームデリミターとして機能します。
The CRC is 4-bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface.
CRCの長さは4バイトで、FDDIで使用される同じ32ビット多項式を使用し、ANSI X3.139ファイバー分布データインターフェイスで指定されています。
The Frame Header is 24-bytes long and has several fields that are associated with the identification and control of the payload. Some of the values and options for this field that are relevant to the IP and ARP payloads are discussed in Section 7.
フレームヘッダーの長さは24バイトで、ペイロードの識別と制御に関連するいくつかのフィールドがあります。IPおよびARPペイロードに関連するこのフィールドの値とオプションの一部については、セクション7で説明します。
Current FC Standards allow up to 3 Optional Header fields [11]:
現在のFC標準では、最大3つのオプションのヘッダーフィールドが許可されています[11]：
- Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes).
- network_header（16バイト） - association_header（32バイト） - device_header（最大64バイト）。
The IP and ARP FC Sequences SHALL carry only the Network_Header field which is 16-bytes long. Other types of optional headers SHALL NOT be used. The Network_Header is REQUIRED in all ARP packets and in the first frame of a logical sequence carrying an IP payload as described below.
IPおよびARP FCシーケンスは、長さ16バイトのNetwork_Headerフィールドのみを運ぶものとします。他のタイプのオプションヘッダーは使用してはなりません。Network_headerは、すべてのARPパケットと、以下に説明するようにIPペイロードを運ぶ論理シーケンスの最初のフレームに必要です。
An application level payload such as IP is called an Information Unit at the FC-4 Level. Lower FC levels map this to a FC Sequence. (See Appendix E.2 for a description of Sequences and Information Units.) Typically, a Sequence consists of more than one frame. Larger user data is segmented and reassembled using two methods: Sequence Count and Relative Offset [18]. With the use of Sequence Count, data blocks are sent using frames with increasing sequence counts (modulo 65536) and it is quite straightforward to detect the first frame that contains the Network_Header. When Relative Offset is used, as frames arrive, some computation is required to detect the first frame that contains the Network_Header. Sequence Count and Relative Offset field control information, is carried in the FC Header.
IPなどのアプリケーションレベルのペイロードは、FC-4レベルの情報ユニットと呼ばれます。より低いFCレベルは、これをFCシーケンスにマッピングします。（シーケンスと情報単位の説明については、付録E.2を参照してください。）通常、シーケンスは複数のフレームで構成されています。より大きなユーザーデータは、シーケンスカウントと相対オフセットの2つの方法を使用してセグメント化され、再組み立てされています[18]。シーケンスカウントを使用すると、データブロックはシーケンスカウントが増加するフレームを使用して送信され（Modulo 65536）、Network_headerを含む最初のフレームを検出するのは非常に簡単です。フレームが到着すると、相対的なオフセットが使用されると、Network_Headerを含む最初のフレームを検出するためにある程度の計算が必要です。シーケンスカウントと相対的なオフセットフィールド制御情報は、FCヘッダーに掲載されています。
In FC, the physical temporal ordering of the frames as it arrives at a destination can be different from that of the order sent because of traversing through a FC Network.
FCでは、FCネットワークを通過するために送信された順序の物理的な時間的順序は、FCネットワークを通過するために送信される注文の物理的な順序とは異なります。
When IP forms the FC Payload then only the first frame of the logical Sequence SHALL include the FC Network_Header. Fig. 2 shows the logical First Frame and logical subsequent frames. Since frames may arrive out of order, detection of the first frame of the logical FC Sequence is necessary.
IPがFCペイロードを形成する場合、論理シーケンスの最初のフレームのみがFC Network_Headerを含めるものとします。図2は、論理的な最初のフレームと論理的な後続のフレームを示しています。フレームは順番に到着する可能性があるため、論理FCシーケンスの最初のフレームの検出が必要です。
ARP packets map to a single frame FC Sequence and SHALL always carry the FC Network_Header.
ARPパケットは、単一のフレームFCシーケンスにマッピングされ、常にFC Network_Headerを搭載するものとします。
Note the definition of FC Data Field and FC Frame Payload in Fig. 1. FC Data Field includes the FC Frame Payload and the FC Optional Header, that is, Frame Payload definition does not include the FC Optional Header. One or more Frame Payloads together make the FC Sequence Payload as shown in Fig 2 and discussed further in Sections 3.2 and 3.4. FC Sequence Payload includes the mapped IP or ARP packet along with the LLC/SNAP headers.
図1のFCデータフィールドとFCフレームペイロードの定義に注意してください。FCデータフィールドには、FCフレームペイロードとFCオプションヘッダーが含まれます。つまり、フレームペイロード定義にはFCオプションヘッダーが含まれません。図2に示すように、1つ以上のフレームペイロードがFCシーケンスペイロードを作成し、セクション3.2および3.4でさらに説明します。FCシーケンスペイロードには、LLC/SNAPヘッダーとともに、マッピングされたIPまたはARPパケットが含まれます。
First Frame of a Logical FC Sequence
---+------------+---------------------------+----------//----------+---
| FC Header | FC Network_Header | FC Sequence Payload |
---+------------+---------------------------+---------//-----------+---
Subsequent Frames of a Logical FC Sequence
--+-----------+--------------//----------------+--
| FC Header | Additional FC Sequence Payload |
--+-----------+-------------//-----------------+--
Fig. 2 FC Network_Header in a Frame Sequence
図2フレームシーケンスのFC Network_header
The SOF, CRC, EOF control fields of the FC frame and other optional headers have been omitted in the figure for clarity.
FCフレームのSOF、CRC、EOF制御フィールド、およびその他のオプションヘッダーは、明確にするために図で省略されています。
An FC Information Unit specific to each protocol such as IP is defined in FC-4. This defines the upper bound on the size of the information that can be transported.
IPなどの各プロトコルに固有のFC情報ユニットは、FC-4で定義されています。これにより、輸送できる情報のサイズに関する上限が定義されます。
Each IP or ARP Packet is mapped to a single FC Information Unit, which in turn is mapped to a single FC Sequence. There is a one-to-one mapping between an IP or ARP packet and a FC Sequence.
各IPまたはARPパケットは、単一のFC情報ユニットにマッピングされ、単一のFCシーケンスにマッピングされます。IPパケットまたはARPパケットとFCシーケンスの間に1対1のマッピングがあります。
Fibre Channel limits the size of a single Information Unit to 2^32-1, which is very large [2]. However, since the Maximum Transmission Unit (MTU) size of an IPv4 packet does not exceed 65,536-bytes, the mapped IPv4 size is far below the 2^32-1 limit.
ファイバーチャネルは、単一の情報ユニットのサイズを2^32-1に制限します。これは非常に大きい[2]。ただし、IPv4パケットの最大透過ユニット（MTU）サイズは65,536バイトを超えないため、マッピングされたIPv4サイズは2^32-1の制限をはるかに下回ります。
IPv4 Packet definition includes the IP Payload and IP Headers - both fixed and optional. The corresponding FC Sequence Payload includes the LLC/SNAP Header and the IPv4 packet.
IPv4パケット定義には、IPペイロードとIPヘッダーが含まれます。これは、固定とオプションの両方です。対応するFCシーケンスペイロードには、LLC/SNAPヘッダーとIPv4パケットが含まれます。
As noted above, the greatest length allowed for an IPv4 Packet including any optional headers and independent of this standard is 65,536-bytes. However, limiting the IP MTU size to 65,280-bytes helps in buffer resource allocation at N_Ports and also allows for up to 256-bytes of overhead. Since the FC Network_Header requires 16-bytes and the IEEE 802.2 LLC/SNAP header requires 8 bytes, it leaves 232 bytes for future use.
上記のように、オプションのヘッダーを含むIPv4パケットに可能な最大の長さは、この標準とは独立していることを含む65,536バイトです。ただし、IP MTUサイズを65,280バイトに制限すると、N_PORTSでのバッファリソース割り当てに役立ち、最大256バイトのオーバーヘッドも可能になります。FC Network_Headerは16バイトを必要とし、IEEE 802.2 LLC/SNAPヘッダーには8バイトが必要なため、将来の使用のために232バイトを残します。
All implementations SHALL restrict the IP MTU size to 65,280 bytes and the corresponding FC Sequence Payload size to 65536-bytes.
すべての実装は、IP MTUサイズを65,280バイトに制限し、対応するFCシーケンスペイロードサイズを65536バイトに制限するものとします。
In order for IP fragmentation and reassembly to work properly it is necessary that every implementation of IP be capable of transporting a maximally minimum size IP packet without fragmentation. A maximally minimum size IP Packet is defined as an IP Packet with an 8-byte payload (the smallest possible non-zero payload size for a fragment) and a 60-byte header (the largest possible header consisting of a 20-byte fixed part and a maximum size option field of 40-bytes) [17].
IPの断片化と再組み立てが適切に機能するためには、IPのすべての実装が断片化なしで最大サイズのIPパケットを輸送できることが必要です。最大最小サイズのIPパケットは、8バイトペイロード（フラグメントの可能な限り最小の非ゼロペイロードサイズ）と60バイトヘッダー（20バイト固定部品で構成される最大のヘッダーを備えたIPパケットとして定義されます。40バイトの最大サイズオプションフィールド）[17]。
All implementations SHALL support a FC Data Field of 92-bytes, which is required to support 68-bytes of the maximally minimum sized IP Packet, 16-bytes of the FC Network_Header, and 8-bytes of the LLC/SNAP Header.
すべての実装は、92バイトのFCデータフィールドをサポートするものとします。これは、最大サイズのIPパケットの68バイト、FC Network_Headerの16バイト、およびLLC/SNAPヘッダーの8バイトをサポートするために必要です。
The ARP packet has a fixed size of 28-bytes. All implementations SHALL support a FC Data Field size of 52-bytes, which is required to support 28-bytes of an ARP Packet, 16-bytes of the FC Network_Header, and 8-bytes of the LLC/SNAP Header. Note that the minimum MTU requirement for ARP is already covered by the minimum MTU requirement for IP but it is mentioned here for completeness.
ARPパケットの固定サイズは28バイトです。すべての実装は、52バイトのFCデータフィールドサイズをサポートします。これは、ARPパケットの28バイト、FC Network_Headerの16バイト、およびLLC/SNAPヘッダーの8バイトをサポートするために必要です。ARPの最小MTU要件は、IPの最小MTU要件ですでにカバーされているが、完全性についてはここで言及されていることに注意してください。
The InARP packet is identical in size to the ARP and the same MTU requirements apply.
INARPパケットのサイズはARPと同一であり、同じMTU要件が適用されます。
The FARP Command is a FC Extended Link Service (ELS) command and maps directly to the FC Data Field without the LLC/SNAP or the FC Network_Header. The FARP Command has a fixed size of 76-bytes. Because FARP operates purely in the FC space, it places no special MTU requirements in this specification.
FARPコマンドはFC拡張リンクサービス（ELS）コマンドであり、LLC/SNAPまたはFC Network_HeaderなしでFCデータフィールドに直接マップします。FARPコマンドの固定サイズは76バイトです。FARPはFCスペースで純粋に動作するため、この仕様に特別なMTU要件はありません。
FC devices are identified by Nodes and their Ports. A Node is a collection of one or more Ports identified by a unique nonvolatile 64-bit World Wide Node name (WW_NN). Each Port in a node, is identified with a unique nonvolatile 64-bit World Wide Port name (WW_PN), and a volatile Port Identifier (Port_ID).
FCデバイスは、ノードとそのポートによって識別されます。ノードは、一意の不揮発性の64ビットワールドワイドノード名（ww_nn）によって識別される1つ以上のポートのコレクションです。ノード内の各ポートは、一意の不揮発性64ビットワールドワイドポート名（ww_pn）と揮発性ポート識別子（port_id）で識別されます。
Port_IDs are 24-bits long. A FC frame header carries a Source Port_ID (S_ID) and a Destination Port_ID (D_ID). The Port_ID of a given port is volatile. (The mechanism(s) by which a Port_ID may change in a FC topology is outside the scope of this document. See Appendix D).
PORT_IDSは24ビットの長さです。FCフレームヘッダーには、ソースPORT_ID（S_ID）と宛先PORT_ID（D_ID）が搭載されています。特定のポートのport_idは揮発性です。（FCトポロジでPORT_IDが変化する可能性のあるメカニズムは、このドキュメントの範囲外です。付録Dを参照）。
The FC Network_Header is normally optional in FC Standards, but REQUIRED in this specification. A FC Network_Header carries source and destination WW_PNs. A WW_PN consists of a 60-bit Network Address and a upper 4-bit Network Address Authority (NAA) field as shown in Fig. 3. The 4-bit NAA field is used to distinguish between the various name registration authorities used to define the Network Address [2].
FC Network_Headerは通常、FC標準ではオプションですが、この仕様では必要です。FC Network_Headerには、ソースと宛先WW_PNSが含まれます。WW_PNは、図3に示すように、60ビットネットワークアドレスと4ビットネットワークアドレス局（NAA）フィールドで構成されています。4ビットNAAフィールドは、4ビットNAAフィールドを使用して、さまざまな名前登録機関を使用して使用されるさまざまな名前登録機関を定義するために使用されます。ネットワークアドレス[2]。
In this specification, both the Source and Destination 4-bit NAA identifiers SHALL be set to binary '0001' indicating that an IEEE 48-bit MAC address is contained in the lower 48 bits of the network address fields. The high order 12 bits in the network address fields SHALL be set to 0x0000. The NAA field value equal to binary '0001' allows FC networks to be bridged with other FC networks or traditional LANs.
この仕様では、ソースと宛先4ビットNAA識別子の両方をバイナリ「0001」に設定する必要があります。ネットワークアドレスフィールドの高次の12ビットは、0x0000に設定する必要があります。バイナリ「0001」に等しいNAAフィールド値により、FCネットワークは他のFCネットワークまたは従来のLANで架かることができます。
+--------+---------------------------------------+
| D_NAA |Network_Dest_Address (High-order bits) |
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Dest_Address (Low-order bits) |
| (32 bits) |
+--------+---------------------------------------+
| S_NAA |Network_Source_Address(High-order bits)|
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Source_Address (Low-order bit) |
| (32 bits) |
+--------+---------------------------------------+
Fig. 3 Format of the Network_Header Field
図3 Network_Headerフィールドの形式
FC Payload with IP:
IPを使用したFCペイロード：
An FC Sequence Payload carrying an IP and ARP packet SHALL use the formats shown in Figs. 4 and 5 respectively. Both formats use the 8-byte LLC/SNAP header.
IPおよびARPパケットを運ぶFCシーケンスペイロードは、図2と図2に示す形式を使用するものとします。それぞれ4と5。どちらの形式も8バイトLLC/SNAPヘッダーを使用します。
+-----------------+-----------+------------+-------------//----------+
| LLC/SNAP Header | IP Header | Opt.IP Hdr.| IP Data |
| (8 bytes) | (20 bytes)| (40 bytes | (65280 -IP Header |
| | | Max) | - Opt. IP Hdr.) bytes |
+-----------------+-----------+------------+-------------//----------+
Fig. 4 Format of FC Sequence Payload carrying IP
図4 FCシーケンスペイロードを運ぶIPの形式
FC Sequence Payload with ARP:
ARPを使用したFCシーケンスペイロード：
As noted earlier, FC frames belonging to the same Sequence may be delivered out of order over a Fabric. If the Relative Offset method is used to identify FC Sequence Payload fragments, then the IP Header MUST appear in the frame that has a relative offset of 0.
前述のように、同じシーケンスに属するFCフレームは、ファブリック上で順番に配信される場合があります。相対オフセットメソッドを使用してFCシーケンスペイロードフラグメントを識別する場合、IPヘッダーは0の相対オフセットを持つフレームに表示する必要があります。
+-----------------+-------------------+
| LLC/SNAP Header | ARP Packet |
| (8 bytes) | (28 bytes) |
+-----------------+-------------------+
Fig. 5 Format of FC Sequence Payload carrying ARP
図5 FCシーケンスペイロードの形式ARP
FC Sequence Payload with FARP:
FARPを使用したFCシーケンスペイロード：
FARP Protocol commands are directly mapped to the Frame Sequence Payload and are 76-bytes long. No LLC/SNAP Header or FC Network_Header is used and therefore the FC Data Field size simply consists of the FC Sequence Payload.
FARPプロトコルコマンドは、フレームシーケンスペイロードに直接マッピングされ、長さは76バイトです。LLC/SNAPヘッダーまたはFC Network_Headerが使用されないため、FCデータフィールドサイズはFCシーケンスペイロードで構成されています。
LLC:
LLC：
A Logical Link Control (LLC) field along with a Sub Network Access Protocol (SNAP) field is a method used to identify routed and bridged non-OSI protocol PDUs and is defined by IEEE 802.2 and applied to IP in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless mode), the LLC header is 3-bytes long and consists of a 1-byte Destination Service Access Point (DSAP)field, a 1-byte Source Service Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 6.
論理リンクコントロール（LLC）フィールドとサブネットワークアクセスプロトコル（SNAP）フィールドは、ルーティングされた非OSIプロトコルPDUを識別するために使用される方法であり、IEEE 802.2で定義され、[8]でIPに適用されます。LLC Type 1操作（つまり、承認されていないコネクションレスモード）では、LLCヘッダーは長さ3バイトで、1バイトの宛先サービスアクセスポイント（DSAP）フィールド、1バイトのソースサービスアクセスポイント（SSAP）フィールドで構成されています。図6に示すように、1バイト制御フィールド。
+----------+----------+----------+
| DSAP | SSAP | CTRL |
| (1 byte) | (1 byte) | (1 byte) |
+----------+----------+----------+
Fig. 6 LLC Format
The LLC's DSAP and SSAP values of 0xAA indicate that an IEEE 802.2 SNAP header follows. The LLC's CTRL value equal to 0x03 specifies an Unnumbered Information Command PDU. In this specification the LLC Header value SHALL be set to 0xAA-AA-03. Other values of DSAP/SSAP indicate support for other protocols and SHALL NOT be used in this specification.
LLCのDSAP値と0xAAのSSAP値は、IEEE 802.2スナップヘッダーが続くことを示しています。LLCのCtrl値は0x03に等しいです。この仕様では、LLCヘッダー値を0xAA-AA-03に設定する必要があります。DSAP/SSAPの他の値は、他のプロトコルのサポートを示しており、この仕様では使用してはなりません。
SNAP:
スナップ：
The SNAP Header is 5-bytes long and consists of a 3-byte Organizationally Unique Identifier (OUI) field and a 2-byte Protocol Identifier (PID) as shown in Fig. 7
スナップヘッダーは5バイトの長さで、図7に示すように、3バイトの組織的に一意の識別子（OUI）フィールドと2バイトプロトコル識別子（PID）で構成されています。
+------+------+-------+------+------+
| OUI | PID |
| ( 3 bytes) | (2 bytes) |
+------+------+-------+------+------+
Fig. 7 SNAP Format
SNAP was invented to "encapsulate" LAN frames within the payload. The SNAP OUI value equal to 0x00-00-00 specifies that the PID is an EtherType (i.e., routed non-OSI protocol).
スナップは、ペイロード内のLANフレームを「カプセル化」するために発明されました。0x00-00-00に等しいSNAP OUI値は、PIDがEtherType（つまり、ルーティングされた非OSIプロトコル）であることを指定しています。
The SNAP OUI value equal to 0x00-80-C2 indicates Bridged Protocols.
0x00-80-C2に等しいSNAP OUI値は、橋渡しプロトコルを示します。
With the OUI value set to 0x00-00-00, the SNAP PID value equal to 0x08-00 indicates IP and a PID value equal to 0x08-06 indicates ARP (or InARP).
OUI値が0x00-00-00に設定されている場合、0x08-00に等しいSNAP PID値はIPを示し、0x08-06に等しいPID値はARP（またはINARP）を示します。
The complete LLC/SNAP Header is shown in Fig. 8.
完全なLLC/SNAPヘッダーを図8に示します。
+-----------+----------+----------+-------+-------+-------+-------+------+
| DSAP | SSAP | CTRL | OUI | PID |
| (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes |
+-----------+----------+----------+-------+-------+-------+-------+------+
Fig. 8 LLC/SNAP Header
図8 LLC/スナップヘッダー
IP or ARP Packets are mapped to FC-4 Level using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [20]. FC-4 Payload maps with no change in order to the FC-2 Level.
IPまたはARPパケットは、標準のネットワークバイトの順序または標準形式に対応する大きなエンディアンバイト順序を使用してFC-4レベルにマッピングされます[20]。FC-2レベルに変更されないFC-4ペイロードマップ。
FC-1 Level defines the method used to encode data prior to transmission and subsequently decode the data upon reception. The method encodes 8-bit bytes into 10-bit transmission characters to improve the transmission characteristics of the serial data stream. In Fibre Channel, data fields are aligned on word boundaries. See Appendix E. A word in FC is defined as 4 bytes or 32 bits. The resulting transmission word after the 8-bit to 10-bit encoding consists of 40 bits.
FC-1レベルは、送信前にデータをエンコードし、その後受信時にデータをデコードするために使用される方法を定義します。このメソッドは、8ビットバイトを10ビット送信文字にエンコードして、シリアルデータストリームの伝送特性を改善します。ファイバーチャネルでは、データフィールドは単語の境界に合わせられます。付録Eを参照してください。FCの単語は、4バイトまたは32ビットとして定義されています。8ビットから10ビットのエンコード後の結果の伝送ワードは、40ビットで構成されています。
Data words or Ordered Sets (special FC-2 Level control words) from the FC-2 Level map to the FC-1 Level with no change in order and the bytes in the word are transmitted in the Most Significant Byte first to Least Significant Byte order. The transmission order of bits within each byte is the Least Significant Bit to the Most Significant Bit.
FC-2レベルマップからFC-1レベルまでのデータワードまたは順序付けセット（特別なFC-2レベル制御ワード）は、順序が変更されず、単語のバイトは最も重要なバイトで最初に最も重要なバイトから最も重要なバイトに送信されます注文。各バイト内のビットの伝送順序は、最も重要なビットから最も重要ではありません。
Address Resolution in this specification is primarily concerned with associating IP addresses with FC Port addresses. As described earlier, FC device ports have two types of addresses:
この仕様のアドレス解決は、主にIPアドレスのFCポートアドレスを関連付けることに関係しています。前述のように、FCデバイスポートには2種類のアドレスがあります。
- a non-volatile unique 64-bit address called World Wide Port_Name (WW_PN) - a volatile 24-bit address called a Port_ID
- World Wide Port_name（ww_pn）と呼ばれる不揮発性のユニークな64ビットアドレス - port_idと呼ばれる揮発性24ビットアドレス
The Address Resolution mechanism therefore will need two levels of mapping:
したがって、アドレス解像度メカニズムには、2つのレベルのマッピングが必要です。
1. A mapping from the IP address to the WW_PN (i.e., IEEE 48-bit MAC address)
1. IPアドレスからww_pnへのマッピング（つまり、IEEE 48ビットMACアドレス）
2. A mapping from the WW_PN to the Port_ID (see Appendix G for a definition of Port_ID)
2. ww_pnからport_idへのマッピング（port_idの定義については、付録Gを参照）
The address resolution problem is compounded by the fact that the Port_ID is volatile and the second mapping MUST be valid before use. Moreover, this validation process can be different depending on the network topology used. Appendix D provides a discussion on validation for the different FC topologies.
アドレス解像度の問題は、PORT_IDが揮発性であり、2番目のマッピングが使用前に有効でなければならないという事実によって悪化します。さらに、この検証プロセスは、使用されるネットワークトポロジによって異なる場合があります。付録Dは、さまざまなFCトポロジの検証に関する議論を提供します。
Architecturally, the first level of mapping and control operation is handled by the Address Resolution Protocol (ARP), and the second level by the FC Address Resolution Protocol (FARP). FARP is described in Section 5.
建築的には、マッピングおよび制御操作の最初のレベルは、アドレス解像度プロトコル（ARP）によって処理され、2番目のレベルはFCアドレス解像度プロトコル（FARP）によって処理されます。FARPはセクション5で説明されています。
Other optional mechanisms in FARP that directly map an IP address to a Port_ID, or WW_NN to a Port_ID are described in Appendix A.
IPアドレスをPORT_IDに直接マッピングするFARPのその他のオプションメカニズム、またはww_nnがport_idに説明されています。付録Aで説明します。
The Inverse Address Resolution Protocol (InARP) is yet another optional mechanism that resolves WW_PN and Port_IDs to IP addresses. InARP is described in Appendix B.
逆アドレス解像度プロトコル（INARP）は、ww_pnとport_idsをIPアドレスに解決するもう1つのオプションメカニズムです。INARPは付録Bに記載されています。
The Address Resolution Protocol (ARP) given in [9] was designed to be a general purpose protocol, and to work with many network technologies, and with many upper layer protocols. Fig 9 shows the ARP packet format based on [9], where the upper layer protocol uses a 4 octet protocol (IP) address and the network technology uses six-octet hardware (MAC) address.
[9]に与えられたアドレス解像度プロトコル（ARP）は、汎用プロトコルであり、多くのネットワークテクノロジー、および多くの上層プロトコルと連携するように設計されています。図9は、[9]に基づくARPパケット形式を示しています。上層プロトコルは4 Octetプロトコル（IP）アドレスを使用し、ネットワークテクノロジーは6オクテットハードウェア（MAC）アドレスを使用します。
The ARP uses two packet types - Request and Reply - and each type of packet is 28 -bytes long in this specification. The ARP Packet fields are common to both ARP Requests and ARP Replys.
ARPは、リクエストと返信の2つのパケットタイプを使用し、各タイプのパケットはこの仕様では28バイの長さです。ARPパケットフィールドは、ARPリクエストとARP返信の両方に共通しています。
The LLC/SNAP encapsulated ARP Request Packet is mapped to a FC Broadcast Sequence and the exact mechanism used to broadcast a FC Sequence depends on the FC topology. This is discussed later in this section. Compliant ARP Request Broadcasts SHALL include Network_Headers.
LLC/SNAPカプセル化ARPリクエストパケットはFCブロードキャストシーケンスにマッピングされ、FCシーケンスのブロードキャストに使用される正確なメカニズムはFCトポロジに依存します。これについては、このセクションの後半で説明します。準拠のARP要求放送には、Network_Headersが含まれます。
The LLC/SNAP encapsulated ARP Reply Packet is mapped to a FC Sequence. Compliant ARP Replys SHALL include Network_Headers.
LLC/SNAPカプセル化ARP応答パケットは、FCシーケンスにマッピングされます。準拠のARP返信には、Network_Headersを含めるものとします。
Note that in all discussions to follow, the WW_PN and the 48-bit MAC address conceptually mean the same thing.
従うべきすべての議論において、ww_pnと48ビットのMacアドレスは概念的に同じことを意味することに注意してください。
The 'HW Type' field SHALL be set to 0x00-01.
「HWタイプ」フィールドは0x00-01に設定する必要があります。
Technically, the correct HW Type value should be set to 0x00-06 according to RFC 1700 indicating IEEE 802 networks. However, as a practical matter a HW Type value of 0x00-06 is known to cause rejections from some Ethernet end stations when FC is bridged to Ethernet. Translational bridges are normally expected to change this field from Type 6 to 1 and vice versa under these configurations, but many do not. It is because of this reason that the Type Code is set to 1 rather than 6. However, both HW Type values of 0x00-01 and 0x00-06 SHALL be accepted.
技術的には、正しいHWタイプの値は、IEEE 802ネットワークを示すRFC 1700に従って0x00-06に設定する必要があります。ただし、実際の問題として、FCがイーサネットにブリッジされた場合、0x00-06のHWタイプの値は、一部のイーサネットエンドステーションから拒否を引き起こすことが知られています。翻訳ブリッジは通常、このフィールドをタイプ6から1に変更すると予想されます。これらの構成の下ではその逆ですが、多くはそうではありません。この理由により、タイプコードは6ではなく1に設定されています。ただし、0x00-01と0x00-06のHWタイプ値の両方が受け入れられます。
The 'Protocol' field SHALL be set to 0x08-00 indicating IP protocol.
「プロトコル」フィールドは、IPプロトコルを示す0x08-00に設定するものとします。
The 'HW Addr Length' field SHALL be set to 0x06 indicating 6-bytes of HW address.
「HW addr length」フィールドは、HWアドレスの6バイトを示す0x06に設定する必要があります。
The 'Protocol Addr Length' field SHALL be set to 0x04 indicating 4- bytes of IPv4 address.
「プロトコルADDR長」フィールドは、IPv4アドレスの4バイトを示す0x04に設定する必要があります。
The 'Operation' Code field SHALL be set as follows:
「操作」コードフィールドは、次のように設定するものとします。
0x00-01 for ARP Request 0x00-02 for ARP Reply
ARP要求の0x00-01 ARP応答の0x00-02
The 'HW Addr of Sender' field SHALL be the 6-byte IEEE MAC address of the sender. It is either the Requester (ARP Request) or the Responder (ARP Reply) address.
「送信者のHWアドオン」フィールドは、送信者の6バイリテIEEE MACアドレスでなければなりません。これは、リクエスター（ARPリクエスト）またはレスポンダー（ARP応答）アドレスのいずれかです。
The 'Protocol Addr of Sender' field SHALL be the 4-byte IP address of the Requester (ARP Request) or that of the Responder (ARP Reply).
「送信者のプロトコルADDR」フィールドは、リクエスター（ARPリクエスト）またはレスポンダー（ARP応答）の4バイトIPアドレスとするものとします。
The 'HW Addr of Target' field SHALL be set to zero during an ARP Request and to the 6-byte MAC address of the Requester (ARP Request) in an ARP Reply.
「ターゲットのHW Addr」フィールドは、ARPリクエスト中にゼロに設定し、ARP返信でリクエスターの6バイトMACアドレス（ARPリクエスト）に設定するものとします。
The 'Protocol Addr of Target' field SHALL be set to the 4-byte IP address of the Responder (ARP Reply) in a ARP Request, and to the 4-byte IP address of the Requester (ARP Request) in an ARP Reply.
「ターゲットのプロトコル」フィールドは、ARPリクエストのレスポンダー（ARP応答）の4バイトIPアドレス、およびARP応答のリクエスター（ARPリクエスト）の4バイトIPアドレスに設定するものとします。
+-------------------------+
| HW Type | 2 bytes
+-------------------------+
| Protocol | 2 bytes
+-------------------------+
| HW Addr Length | 1 byte
+-------------------------+
| Protocol Addr Length | 1 byte
+-------------------------+
| Op Code | 2 bytes
+-------------------------+
| HW Addr of Sender | 6 bytes
+-------------------------+
| Protocol Addr of Sender | 4 bytes
+-------------------------+
| HW Addr of Target | 6 bytes
+-------------------------+
| Protocol Addr of Target | 4 bytes
+-------------------------+
Total 28 bytes
Fig. 9 ARP Packet Format
Whenever a FC port wishes to send IP data to another FC port, then the following steps are taken:
FCポートがIPデータを別のFCポートに送信したい場合はいつでも、次の手順が取られます。
1. The source port should first consult its local mapping tables to determine the <destination IP address, destination WW_PN>.
1. ソースポートは、最初にローカルマッピングテーブルを参照して、<宛先IPアドレスである宛先ww_pn>を決定する必要があります。
2. If such a mapping is found, then the source sends the IP data to the port whose WW_PN address was found in the table.
2. そのようなマッピングが見つかった場合、ソースはIPデータをテーブルにww_pnアドレスが見つかったポートに送信します。
3. If such a mapping is not found, then the source sends an ARP Request broadcast to its connected FC network in anticipation of getting a reply from the correct destination along with its WW_PN.
3. そのようなマッピングが見つからない場合、ソースは、ww_pnとともに正しい宛先から返信を取得することを見越して、接続されたFCネットワークにARP要求を送信します。
4. When an ARP Request Broadcast frame is received by a node with the matching IP address, it generates an ARP Reply. Since the ARP Reply must be addressed to a specific destination Port_ID, the FC layer mapping between the WW_PN and Port_ID (of the ARP Request orginator) MUST be valid before the reply is sent.
4. ARP要求ブロードキャストフレームが、一致するIPアドレスを備えたノードで受信されると、ARP応答が生成されます。ARPの返信は特定の宛先PORT_IDに宛ててアドレス指定する必要があるため、返信が送信される前に、ww_pnとport_id（arp request orginatorの）の間のFCレイヤーマッピングは有効でなければなりません。
5. If no node has the matching IP address, the result is a silent behavior.
5. 一致するIPアドレスがないノードがない場合、結果はサイレント動作です。
The ARP Request (Broadcast) and Reply mechanism described above still apply, although there is only one node that receives the ARP Request.
ARP要求（ブロードキャスト）と応答メカニズムは引き続き適用されますが、ARPリクエストを受信するノードは1つだけです。
In a private loop, the ARP Request Broadcast frame is sent using the broadcast method specified in the FC-AL [7]standard.
プライベートループでは、ARP要求ブロードキャストフレームは、FC-AL [7]標準で指定されたブロードキャスト方法を使用して送信されます。
1. The source port first sends an Open Broadcast Replicate primitive (OPN(fr))Signal forcing all the ports in the loop (except itself), to replicate the frames that they receive while examining the frame header's Destination_ID field.
1. ソースポートは、最初に、ループ内のすべてのポートを強制するオープンブロードキャストReplicate Primitive（OPN（FR））信号を送信し、フレームヘッダーのDestination_IDフィールドを調べながら受け取ったフレームを複製します。
2. The source port then removes this OPN(fr) signal when it returns to it.
2. ソースポートは、このOPN（FR）信号を返すと削除します。
3. The loop is now ready to receive the ARP broadcast. The source now sends the ARP Request as a single-frame Broadcast Sequence in a Class 3 frame with the following FC Header D_ID field and F_CTL bits setting:
3. ループは、ARPブロードキャストを受信する準備ができました。ソースは、次のFCヘッダーD_IDフィールドとF_CTLビット設定を備えたクラス3フレームの単一フレームブロードキャストシーケンスとしてARPリクエストを送信します。
Destination ID <Word 0, bit 0:23>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
終了シーケンス<単語2、ビット19>：es = 1。
4. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
4. 準拠のARPブロードキャストシーケンスフレームには、宛先MACアドレスが0xff-ff-ff-ff-ff-ffに設定され、NAA = B'0001に設定されたNetwork_Headerを含める必要があります。
5. The destination port recognizing its IP address in the ARP Request packet SHALL respond with an ARP Reply.
5. ARPリクエストパケット内のIPアドレスを認識する宛先ポートは、ARP応答で応答するものとします。
The following steps will be followed when a port is configured in a public loop:
ポートがパブリックループで構成されている場合、次の手順に従います。
1. A public loop device attached to a fabric through a FL_Port MUST NOT use the OPN(fr) signal primitive. Rather, it sends the broadcast sequence to the FL_Port at AL_PA = 0x00.
1. FL_PORTを介してファブリックに接続されたパブリックループデバイスは、OPN（FR）信号原始を使用してはなりません。むしろ、AL_PA = 0x00のFL_PORTにブロードキャストシーケンスを送信します。
2. A FC Fabric propagates the broadcast to all other ports including the FL_Port which the broadcast arrived on. This includes all F_Ports, and other FL_Ports.
2. FCファブリックは、ブロードキャストが到着したFL_portを含む他のすべてのポートにブロードキャストを伝播します。これには、すべてのf_ports、およびその他のfl_portsが含まれます。
3. On each FL_Port, the fabric propagates the broadcast by first using the primitive signal OPNfr, in order to prepare the loop to receive the broadcast sequence.
3. 各fl_portで、生地は、最初にプリミティブ信号OPNFRを使用してブロードキャストを伝播し、ブロードシーケンスを受信するためにループを準備します。
4. A Broadcast Sequence is now sent on all ports (all FL_ports, F_Ports) in Class 3 frame with:
4. ブロードキャストシーケンスは、クラス3フレームのすべてのポート（すべてのfl_ports、f_ports）で次のように送信されます。
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
終了シーケンス<単語2、ビット19>：es = 1。
5. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
5. 準拠のARPブロードキャストシーケンスフレームには、宛先MACアドレスが0xff-ff-ff-ff-ff-ffに設定され、NAA = B'0001に設定されたNetwork_Headerを含める必要があります。
6. The destination port recognizing its IP address in the ARP Request packet SHALL respond with an ARP Reply.
6. ARPリクエストパケット内のIPアドレスを認識する宛先ポートは、ARP応答で応答するものとします。
1. Nodes directly attached to fabric do not require the OPN(fr) primitive signal.
1. ファブリックに直接接続されているノードは、OPN（FR）プリミティブ信号を必要としません。
2. A Broadcast Sequence is now sent on all ports (all FL_ports, F_Ports) in Class 3 frame with:
2. ブロードキャストシーケンスは、クラス3フレームのすべてのポート（すべてのfl_ports、f_ports）で次のように送信されます。
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
終了シーケンス<単語2、ビット19>：es = 1。
3. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
3. 準拠のARPブロードキャストシーケンスフレームには、宛先MACアドレスが0xff-ff-ff-ff-ff-ffに設定され、NAA = B'0001に設定されたNetwork_Headerを含める必要があります。
4. The destination port recognizing its IP address in the ARP packet SHALL respond with an ARP Reply.
4. ARPパケット内のIPアドレスを認識する宛先ポートは、ARP応答で応答するものとします。
FC Layer Mapping between the WW_PN and the Port_ID is independent of the ARP mechanism and is more closely associated with the details of the FC protocols. Name Server and FC Address Resolution Protocol (FARP) are two formal mechanisms that can be used to create and maintain WW_PN to Port_ID tables.
ww_pnとport_idの間のFCレイヤーマッピングは、ARPメカニズムに依存しないものであり、FCプロトコルの詳細とより密接に関連しています。名前サーバーとFCアドレス解像度プロトコル（FARP）は、ww_pnをport_idテーブルに作成および維持するために使用できる2つの正式なメカニズムです。
FARP is a method using Extended Link Service (ELS) commands that resolves <WW_PN, Port_ID> mappings. The WW_PN to Port_ID address resolution using FARP is especially useful in instances where the Login table entries at a node expire and a Name Server is not available. It is outside the scope of this document to describe Name Server. (See [14].)
FARPは、<ww_pn、port_id>マッピングを解決する拡張リンクサービス（ELS）コマンドを使用したメソッドです。FARPを使用したWW_PNへのアドレス解像度は、ノードのログインテーブルエントリが期限切れになり、名前サーバーが利用できない場合に特に役立ちます。名前サーバーを記述するのは、このドキュメントの範囲外です。（[14]を参照。）
Additional address matching mechanisms that resolve <WW_NN, Port_ID> and <IP addr., Port_ID> mapping have been added to FARP. These additional mechanisms are optional and described in Appendix A. Direct IP address to Port_ID mapping is useful in applications where there is no visibility of the MAC address.
<ww_nn、port_id>、<ip addr。、port_id>マッピングを解決する追加のアドレスマッチングメカニズムがFARPに追加されました。これらの追加メカニズムはオプションであり、付録Aで説明されています。MACアドレスの可視性がないアプリケーションでは、PORT_IDマッピングへの直接IPアドレスが役立ちます。
Other less formal FC Layer Mapping mechanisms are described in Appendix C.
他の形式的ではないFC層マッピングメカニズムについては、付録Cで説明します。
Since Port_IDs are volatile, all mapped Port_IDs at all times MUST be valid before use. There are many events that can invalidate this mapping. Appendix D discusses conditions when such a validation is required.
port_idsは揮発性であるため、使用する前に常にすべてのマッピングされたport_idsは有効でなければなりません。このマッピングを無効にすることができる多くのイベントがあります。付録Dは、そのような検証が必要な場合の条件について説明します。
The FARP protocol uses two ELS commands - FARP-REQ and FARP-REPLY.
FARPプロトコルは、FARP-REQとFARP-Replyの2つのELSコマンドを使用しています。
Note: In the following discussion 'Requester' means the node issuing the FARP-REQ ELS message; 'Responder' means the node replying to the request by sending the FARP-REPLY command.
注：次の議論では、「要求者」とは、FARP-REQ ELSメッセージを発行するノードを意味します。「レスポンダー」とは、FARP-Replyコマンドを送信して、ノードがリクエストに返信することを意味します。
The FARP-REQ ELS Broadcast Request command is used to retrieve a specific node's current Port_ID given its unique WW_PN. This Port_ID is sent in a FARP-REPLY unicast command.
FARP-REQ ELSブロードキャストリクエストコマンドは、一意のww_pnを与えられた特定のノードの現在のport_idを取得するために使用されます。このPORT_IDは、FARP-Reply Unicastコマンドで送信されます。
The FARP-REQ may indicate that the Responder:
FARP-REQは、応答者を示している可能性があります。
- Perform only a Login with it (Requester) or, - Send only a FARP-REPLY or, - Perform a Login and send a FARP-REPLY.
- ログインのみを実行します（requester）または - Farp Replyのみを送信するか、 - ログインを実行してFARPリプを送信します。
No sequence initiative is transferred with the FARP-REQ and therefore no Reply (ACCEPT or REJECT) follows this command.
FARP-REQを使用してシーケンスイニシアチブは転送されないため、このコマンドに従うことはできません（受け入れまたは拒否）。
Since a Sequence Initiative is transferred with the FARP-REPLY, either a ACCEPT or REJECT follows this command as a response.
SequenceイニシアチブはFARP-Replyとともに転送されるため、このコマンドは応答としてこのコマンドに従います。
Reception of a FARP-REQ requires a higher level entity at the responding node to send a FARP-REPLY or perform a Port Login.
FARP-REQの受信には、Responsingノードでより高いレベルのエンティティが必要です。FARP応答を送信するか、ポートログインを実行します。
You do not have to be logged in to issue a FARP Request. Also, you do not have to be logged in to the FARP Requester to issue a FARP-REPLY.
FARPリクエストを発行するためにログインする必要はありません。また、FARPリクエスト担当者にログインする必要はありません。
The FARP Protocol Steps:
FARPプロトコルの手順：
FARP-REQ (ELS broadcast) Request Sequence
FARP-REQ（ELSブロードキャスト）要求シーケンス
(No Reply Sequence)
（返信シーケンスなし）
FARP-REPLY (ELS command) Sequence
FARP-Reply（ELSコマンド）シーケンス
Accept/Reject Reply Sequence
返信シーケンスを受け入れ/拒否します
The FARP Protocol Format [2] and Size:
FARPプロトコル形式[2]とサイズ：
FT_1, 76-bytes fixed size
FT_1、76バイト固定サイズ
The FARP Protocol Addressing:
FARPプロトコルアドレス指定：
- In a FARP-REQ, the S_ID in the FC Header designates the Requester's Port ID. The D_ID in the FC Header is the broadcast identifier 0xFF-FF-FF.
- FARP-REQでは、FCヘッダーのS_IDが要求者のポートIDを指定します。FCヘッダーのD_IDは、ブロードキャスト識別子0xff-ff-ffです。
- In a FARP-REPLY, the S_ID in the FC Header designates the Responder's Port_ID. The D_ID in the FC Header is the Requester's Port_ID.
- FARP-Replyでは、FCヘッダーのS_IDはResponderのPORT_IDを指定します。FCヘッダーのD_IDは、RequesterのPORT_IDです。
FARP-REQ and FARP-REPLY commands have identical formats (76-bytes fixed size) and fields but use different command codes. See tables below.
FARP-REQおよびFARP-Replyコマンドには、同じ形式（76バイト固定サイズ）とフィールドがありますが、異なるコマンドコードを使用します。以下の表を参照してください。
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x54-00-00-00 | 4 | Request Command Code|
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Supplied by |
| | | Requester = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Response Action to |
| | | be taken |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------------+---------+---------------------+
| WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
+ WW_NN of Requester | 8 |OPTIONAL; |
| | |See Appendix A |
+-------------------------------------+---------+---------------------+
| WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
| WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x55-00-00-00 | 4 | Reply Command Code |
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Extracted from |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Supplied by |
| | | Responder = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
|WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Requester | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Add. of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
Following is a description of the address fields in the FARP Commands.
以下は、FARPコマンドのアドレスフィールドの説明です。
Port_ID of Requester:
requesterのport_id：
It is the 24-bit Port_ID used in the S_ID field of the FC Header of a FARP-REQ. It is supplied by the Requester in a FARP-REQ and retained in a FARP-REPLY.
FARP-REQのFCヘッダーのS_IDフィールドで使用される24ビットPORT_IDです。リクエスターからFARP-REQで供給され、FARP無反応で保持されます。
Port_ID of Responder:
Responderのport_id：
It is the 24-bit Port_ID used in the S_ID field of the FC Header of a FARP-REPLY. It SHALL be set to 0x00-00-00 in a FARP-REQ. It is supplied by the Responder in a FARP-REPLY.
FARP-ReplyのFCヘッダーのS_IDフィールドで使用される24ビットPORT_IDです。FARP-Reqで0x00-00-00に設定するものとします。ResponderからFARP Replyで供給されます。
WW_PN:
ww_pn：
This address field is used with the b'001', b'011', b'101, b'111', Match Address Code Points. See Match Address Code Point Table below. The Requester supplies the unique 8-byte WW_PN of the Requester and the Responder. It is retained in a FARP-REPLY.
このアドレスフィールドは、B'001 '、B'011'、B'101、B'111 'で使用されます。以下の一致アドレスコードポイントテーブルを参照してください。リクエスターは、リクエスターとレスポンダーの一意の8バイトWW_PNを提供します。それはFARP-Replyで保持されます。
WW_NN:
ww_nn：
The WW_NN address field is used with Match Address Code Points b'010', b'011', b'110', and b'111', which are all optional. Its usage is fully described in Appendix A. When the WW_NN field is not used it SHALL be either set to '0' or a valid non-zero address.
ww_nnアドレスフィールドは、一致アドレスコードポイントb'010 '、b'011'、b'110 '、およびb'111'で使用されます。これらはすべてオプションです。その使用法は、付録Aで完全に説明されています。WW_NNフィールドを使用していない場合は、「0」または有効な非ゼロアドレスに設定されます。
IPv4:
IPv4：
The IPv4 address field is used with the Match Address Code Points b'100', b'101', b'110', and b'111', which are all optional. Its usage is fully described in Appendix A. When the IP Address field is not used it SHALL be either set to '0' or a valid IP address. A valid IP address consists of the 32-bit IPv4 Address with the upper 96 bits set to '0'.
IPv4アドレスフィールドは、一致アドレスコードポイントb'100 '、b'101'、b'110 '、およびb'111'で使用されます。これらはすべてオプションです。その使用法は、付録Aで完全に説明されています。IPアドレスフィールドを使用していない場合は、「0」または有効なIPアドレスに設定されます。有効なIPアドレスは、上部96ビットが「0」に設定された32ビットIPv4アドレスで構成されています。
For each receipt of the FARP-REQ Broadcast ELS, the recipients match one or more addresses based on the encoded bits of the "FARP Match Address Code Points" field shown in the table below. FARP operation with the Match Address Code Point equal to b'001' is described in this section. Other code points are OPTIONAL and are discussed in Appendix A. The upper 5 bits of the Match Address Code Point byte are unused and their use is not currently defined.
FARP-REQブロードキャストELの受領ごとに、受信者は、以下の表に示す「FARP一致アドレスコードポイント」フィールドのエンコードされたビットに基づいて、1つ以上のアドレスを一致させます。このセクションでは、B'001 'に等しいマッチアドレスコードポイントを使用したFARP操作について説明します。他のコードポイントはオプションであり、付録Aで説明します。一致アドレスコードポイントバイトの上部5ビットは未使用であり、その使用は現在定義されていません。
+------------------------------------------------------------------+
| Match Address Code Points |
+------------------------------------------------------------------+
| LSBits | Bit name | Action |
+-----------+--------------------+---------------------------------+
| 000 | Reserved | |
+-----------+--------------------+---------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-----------+--------------------+---------------------------------+
| 010 | MATCH_WW_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 100 | MATCH_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
When a node receives a FARP-REQ with Code Point b'001', it checks its WW_PN against the one set in 'WW_PN of Responder' field of the FARP-REQ command. If there is a match, then the node issues a response according to the action indicated by the FARP Responder Flag. See table below.
ノードがCode Point B'001 'を使用してFARP-REQを受信すると、FARP-REQコマンドの「Responderのww_pn」フィールドにある1つのセットに対してww_pnをチェックします。一致がある場合、ノードは、FARPレスポンダーフラグで示されるアクションに従って応答を発行します。以下の表を参照してください。
WW_NN and IPv4 address fields are not used with the b'001' Code Point operation. They SHALL be set to '0' or a valid address either by the Requester or the Requester and the Responder.
WW_NNおよびIPv4アドレスフィールドは、B'001 'コードポイント操作では使用されません。それらは、要求者またはリクエスターとレスポンダーによって「0」または有効なアドレスに設定されます。
Note that there can be utmost one FARP-REPLY per FARP-REQ.
FARP-REQごとに最大のFARP-Replyが存在する可能性があることに注意してください。
The Responder Flags define what Responder action to take if the result of the Match Address Code Points is successful. 'Responder Flags' is an 8-bit field (bits 0-7) and is defined in the table below. This field is used only in a FARP-REQ. This field is retained unchanged in a FARP-REPLY. If no bits are set, the Responder will take no action.
レスポンダーフラグは、マッチアドレスコードポイントの結果が成功した場合に、どのレスポンダーアクションを実行するかを定義します。「レスポンダーフラグ」は8ビットフィールド（ビット0〜7）であり、下の表で定義されています。このフィールドは、Farp-Reqでのみ使用されます。このフィールドは、FARPの繰り返しで変更されていません。ビットが設定されていない場合、レスポンダーはアクションを実行しません。
+----------+-------------------------------------------------------+
| | FARP Responder Flag |
+----------+----------------+--------------------------------------+
| Bit | Bit Name | Action |
| Position | | |
+----------+----------------+--------------------------------------+
| 0 | INIT_P_LOGI | Initiate a P_LOGI to the Requester |
+----------+----------------+--------------------------------------+
| 1 | INIT_REPLY | Send FARP_REPLY to Requester |
+----------+----------------+--------------------------------------+
| 2 to 7 | Reserved | |
+----------+----------------+--------------------------------------+
If INIT_P_LOGI bit is set then, a Login is performed with the port identified by "Port_ID of Requester" field.
init_p_logiビットが設定されている場合、「requesterのport_id」フィールドで識別されたポートでログインが実行されます。
If INIT_REPLY is set then, a FARP-REPLY is sent to the Port Identified by "Port_ID of Requester" field.
init_replyが設定されている場合、FARP-Replyが「Requesterのport_id」フィールドによって識別されたポートに送信されます。
If both bits are set at the same time, then both Actions are performed.
両方のビットが同時に設定されている場合、両方のアクションが実行されます。
All other bit patterns are undefined at this time and are reserved for possible future use.
他のすべてのビットパターンは現時点では未定義であり、将来の使用の可能性のために予約されています。
Responder action - FARP-REPLY and/or Port Login - for a successful MATCH_WW_PN is always REQUIRED. If there is no address match then a silent behavior is specified.
レスポンダーアクション - FARP -REPLYおよび/またはポートログイン - 成功したMATCH_WW_PNのために常に必要です。アドレスの一致がない場合、サイレント動作が指定されています。
Support for all other Match Address Code Points is OPTIONAL and a silent behavior from the Responder is valid when it is not supported. Recipients of the FARP-REQ ELS SHALL NOT issue a Service Reject (LS_RJT) if FARP OPTIONAL mechanisms are not supported.
他のすべての一致アドレスコードポイントのサポートはオプションであり、レスポンダーからのサイレント動作がサポートされていない場合に有効です。FARP-REQ ELSの受信者は、FARPオプションのメカニズムがサポートされていない場合、サービス拒否（LS_RJT）を発行してはなりません。
In all cases, if there are no matches, then a silent behavior is specified.
すべての場合において、一致がない場合、サイレント行動が指定されます。
If an implementation issues a FARP-REQ with a Match Address Code Point that is OPTIONAL, and fails to receive a response, and the implementation has not obtained the Port_ID of the Responder's port by other means (e.g., prior FARP-REQ with other Code Points), then the implementation SHALL reattempt the FARP-REQ with the MATCH_WW_PN Code Point.
実装がオプションであり、応答を受信できない一致アドレスコードポイントでFARP-REQを発行し、実装が他の手段でレスポンダーのポートのport_idを取得していない場合（例えば、他のコードとの以前のFARP-reqポイント）、その後、実装はMatch_WW_PNコードポイントでFARP-REQを再輸送するものとします。
Getting multiple FARP Replies corresponding to a single FARP-REQ should normally never occur. It is beyond the scope of this document to specify conditions under which this error may occur or what the corrective action ought to be.
単一のFARP-REQに対応する複数のFARP応答を取得すると、通常は発生しないはずです。このドキュメントの範囲を超えて、このエラーが発生する可能性のある条件や、是正措置がどうあるべきかを指定することです。
FC Exchanges shall be established to transfer data between ports. Frames on IP exchanges shall not transfer Sequence Initiative. See Appendix E for a discussion on FC Exchanges.
FC交換は、ポート間でデータを転送するために確立されるものとします。IP交換のフレームは、シーケンスイニシアチブを転送してはなりません。FC交換に関する議論については、付録Eを参照してください。
With the exception of the recommendations in Appendix F, Section F.1, "Reliability in Class 3", the mechanism for aging or expiring exchanges based on activity, timeout, or other method is outside the scope of this document.
付録F、セクションF.1「クラス3の信頼性」の推奨事項を除き、アクティビティ、タイムアウト、またはその他の方法に基づいた老化または期限切れの交換のメカニズムは、このドキュメントの範囲外です。
Exchanges may be terminated by either port. The Exchange Originator may terminate Exchanges by setting the LS bit, following normal FC standard FC-PH [2] rules. This specification prohibits the use of the NOP ELS with LS set for Exchange termination.
交換は、いずれかのポートによって終了する場合があります。Exchange Orignatorは、通常のFC標準FC-PH [2]ルールに従って、LSビットを設定することにより、交換を終了する場合があります。この仕様は、交換終了のためにLSセットを備えたNOP ELSの使用を禁止しています。
Exchanges may be torn down by the Exchange Originator or Exchange Responder by using the ABTS_LS protocol. The use of ABTS_LS for terminating aged Exchanges or error recovery is outside the scope of this document.
ABTS_LSプロトコルを使用して、Exchange OriginatorまたはExchange Responderによって交換が取り壊される場合があります。高齢の交換またはエラー回復を終了するためのABTS_LSの使用は、このドキュメントの範囲外です。
The termination of IP Exchanges by Logout is discouraged, since this may terminate active Exchanges on other FC-4s.
ログアウトによるIP交換の終了は、他のFC-4のアクティブな交換を終了する可能性があるため、落胆しています。
Note: 'Settable' means support is as specified in the relevant standard; all other key words are as defined earlier in this document.
注：「設定可能」とは、サポートが関連する標準で指定されていることを意味します。他のすべてのキーワードは、このドキュメントの前半に定義されています。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Type Code ( = 5) ISO8802-2 LLC/SNAP | REQUIRED | 2 |
| Network_Headers | REQUIRED | 3 |
| Other Optional Headers | MUST NOT | |
+--------------------------------------------------------------------+
Notes:
ノート：
1. This table applies only to FC-4 related data, such as IP and ARP packets. This table does not apply to link services and other non-FC-4 sequences (PLOGI, for example) that must occur for normal operation.
1. この表は、IPやARPパケットなどのFC-4関連データにのみ適用されます。このテーブルは、通常の操作に発生する必要があるリンクサービスやその他の非FC-4シーケンス（Plogiなど）には適用されません。
2. The TYPE field in the FC Header (Word 2 bits 31-24) MUST indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This revision of the document focuses solely on the issues related to running IP and ARP over FC. All other issues are outside the scope of this document, including full support for IEEE 802.2 LLC.
2. FCヘッダーのタイプフィールド（Word 2ビット31-24）は、ISO 8802-2 LLC/SNAPカプセル化（タイプ5）を示す必要があります。ドキュメントのこの改訂は、FCを介したIPとARPの実行に関連する問題のみに焦点を当てています。他のすべての問題は、IEEE 802.2 LLCの完全なサポートを含む、このドキュメントの範囲外です。
3. DF_CTL field (Word 3, bits 23-16 of FC-Header) MUST indicate the presence of a Network_Header (0010 0000) on the First logical Frame of FC-4 Sequences. It should not indicate the presence of a Network_Header on any subsequent frames of the Sequence.
3. DF_CTLフィールド（Word 3、FC-Headerのビット23-16）は、FC-4シーケンスの最初の論理フレームにNetwork_Header（0010 0000）の存在を示す必要があります。シーケンスの後続のフレームにNetwork_Headerの存在を示してはなりません。
R_CTL in FC-Header: Word 0, bits 31-24
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Information Category (R_CTL Routing): | | |
| | | |
| FC-4 Device Data | REQUIRED | 1 |
| Extended Link Data | REQUIRED | |
| FC-4 Link Data | MUST NOT | |
| Video Data | MUST NOT | |
| Basic Link Data | REQUIRED | |
| Link Control | REQUIRED | |
| | | |
| R_CTL information : | | |
| | | |
| Uncategorized | MUST NOT | |
| Solicited Data | MUST NOT | |
| Unsolicited Control | REQUIRED | |
| Solicited Control | REQUIRED | |
| Unsolicited Data | REQUIRED | 1 |
| Data Descriptor | MUST NOT | |
| Unsolicited Command | MUST NOT | |
| Command Status | MUST NOT | |
+--------------------------------------------------------------------+
Notes:
ノート：
1. This is REQUIRED for FC-4 (IP and ARP) packets
1. これは、FC-4（IPおよびARP）パケットに必要です
- Routing bits of R_CTL field MUST indicate Device Data frames (0000) - Information Category of R_CTL field MUST indicate Unsolicited Data (0100)
- R_CTLフィールドのルーティングビットは、デバイスデータフレーム（0000）を示す必要があります。
F_CTL in FC-Header: Word 2, bits 23-0
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Exchange Context | Settable | |
| Sequence Context | Settable | |
| First / Last / End Sequence (FS/LS/ES) | Settable | |
| Chained Sequence | MUST NOT | |
| Sequence Initiative (SI) | Settable | 1 |
| X_ID Reassigned / Invalidate | MUST NOT | |
| Unidirectional Transmit | Settable | |
| Continue Sequence Condition | REQUIRED | 2 |
| Abort Seq. Condition -continue and single Seq.| REQUIRED | 3 |
| Relative Offset - Unsolicited Data | Settable | 4 |
| Fill Bytes | Settable | |
+--------------------------------------------------------------------+
Notes
ノート
1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for sending data to each N_Port in the network and a dedicated RX_ID for receiving data from each N_Port as well. Exchanges are used in a unidirectional mode, thus setting Sequence Initiative is not valid for FC-4 frames. Sequence Initiative is valid when using Extended Link Services.
1. FC-4フレームの場合、各N_PORTには、ネットワーク内の各N_PORTにデータを送信するための専用のOX_IDと、各N_PORTからデータを受信するための専用のRX_IDが必要です。交換は単方向モードで使用されるため、Septing SequenceイニシアチブはFC-4フレームでは無効です。シーケンスイニシアチブは、拡張リンクサービスを使用する場合に有効です。
2. This field is required to be 00, no information.
2. このフィールドは00である必要があり、情報はありません。
3. Sequence error policy is requested by an exchange originator in the F_CTL Abort Sequence Condition bits in the first data frame of the exchange. For Classes 1 and 2, ACK frame is required to be "continuous sequence".
3. シーケンスエラーポリシーは、Exchangeの最初のデータフレームにあるF_CTL Abortシーケンス条件ビットのExchange Orignatorによって要求されます。クラス1と2の場合、ACKフレームは「連続シーケンス」にする必要があります。
4. Relative offset prohibited on all other types (Information Category) of frames.
4. 相対的なオフセットは、フレームの他のすべてのタイプ（情報カテゴリ）で禁止されています。
+---------------------------------------------------------------------+
| Feature | Support |Notes |
+---------------------------------------------------------------------+
| Class 2 open Sequences / Exchange | 1 | 1 |
| Length of Seq. not limited by end-to-end credit | REQUIRED | 2 |
| IP and ARP Packet and FC Data Field sizes | REQUIRED | 3 |
| Capability to receive Sequence of maximum size | OPTIONAL | 4 |
| Sequence Streaming | MUST NOT | 5 |
| Stop Sequence Protocol | MUST NOT | |
| ACK_0 support | OPTIONAL | 6 |
| ACK_1 support | REQUIRED | 6 |
| ACK_N support | MUST NOT | |
| Class of Service for transmitted Sequences | Class | 7 |
| | 1, 2, or 3 | |
| Continuously Increasing Sequence Count | OPTIONAL | 8, 9 |
+---------------------------------------------------------------------+
Notes:
ノート：
1. Only one active sequence per exchange is optional.
1. 交換ごとに1つのアクティブシーケンスのみがオプションです。
2. A Sequence Initiator shall be capable of transmitting Sequences containing more frames than the available credit indicated by a Sequence recipient at Login. FC-PH [2] end-to-end flow control rules will be followed when transmitting such Sequences.
2. シーケンスイニシエーターは、ログイン時のシーケンス受信者が示す利用可能なクレジットよりも多くのフレームを含むシーケンスを送信できるものとします。FC-PH [2]そのようなシーケンスを送信するときに、エンドツーエンドのフロー制御ルールに従います。
3. a) IP MTU size is 65280-bytes and resulting FC Sequence Payload size is 65536-bytes. b) Maximally Minimum IP Packet size is 68-bytes and resulting FC Data Field size is 92-bytes. c) ARP (and InARP) Packet size is 28-bytes and resulting FC Data Field size is 52-bytes.
3. a）IP MTUサイズは65280バイトで、結果のFCシーケンスペイロードサイズは65536バイトです。b）最大の最小IPパケットサイズは68バイトで、結果としてFCデータフィールドサイズは92バイトです。c）ARP（およびINARP）パケットサイズは28バイトで、結果として生じるFCデータフィールドサイズは52バイトです。
4. Some OS environments may not handle the max Sequence Payload size of 65536. It is up to the administrator to configure the Max size for all systems.
4. 一部のOS環境は、65536の最大シーケンスペイロードサイズを処理しない場合があります。すべてのシステムの最大サイズを構成するのは管理者次第です。
5. All class 3 sequences are assumed to be non-streamed.
5. すべてのクラス3シーケンスは、非ストリーミングされていないと想定されています。
6. Only applies for Class 1 and 2. Use of ACK_1 is default, ACK_0 used if indicated by Sequence recipient at Login.
6. クラス1と2にのみ適用されます。ACK_1の使用はデフォルトであり、ログイン時のシーケンスレシピエントで示された場合に使用されます。
7. The administrator configured class of service is used, except where otherwise specified (e.g. Broadcasts are always sent in Class 3).
7. 特別な指定された場合を除き、管理者構成クラスのサービスが使用されます（たとえば、ブロードキャストは常にクラス3で送信されます）。
8. Review Appendix F, "Reliability in Class 3".
8. 付録F、「クラス3の信頼性」を確認します。
9. The first frame of the first sequence of a new Exchange must have SEQ_CNT = 0 [2].
9. 新しい交換の最初のシーケンスの最初のフレームには、SEQ_CNT = 0 [2]が必要です。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| X_ID interlock support | OPTIONAL | 1 |
| OX_ID=FFFF | MUST NOT | |
| RX_ID=FFFF | OPTIONAL | 2 |
| Action if no exchange resources available | P_RJT | 3 |
| Long Lived Exchanges | OPTIONAL | 4 |
| Reallocation of Idle Exchanges | OPTIONAL | |
+--------------------------------------------------------------------+
Notes:
ノート：
1. Only applies to Classes 1 and 2, supported by the Exchange Originator. A Port SHALL be capable of interoperating with another Port that requires X_ID interlock. The Exchange Originator facility within the Port shall use the X_ID Interlock protocol in such cases.
1. Exchange Originatorによってサポートされているクラス1と2にのみ適用されます。ポートは、X_IDインターロックを必要とする別のポートと相互運用できるものとします。ポート内のExchange Originator施設は、そのような場合にX_IDインターロックプロトコルを使用するものとします。
2. An Exchange Responder is not required to assign RX_IDs. If a RX_ID of FFFF is assigned, it is identifying Exchanges based on S_ID / D_ID / OX_ID only.
2. rx_idsを割り当てるために交換リスポンダーは必要ありません。FFFFのRX_IDが割り当てられている場合、S_ID / D_ID / OX_IDのみに基づいて交換を識別しています。
3. In Classes 1 and 2, a Port shall reject a frame that would create a new Exchange with a P_RJT containing reason code "Unable to establish Exchange". In Class 3, the frame would be dropped.
3. クラス1および2では、ポートは、「交換を確立できない」という理由コードを含むP_RJTを使用して新しい交換を作成するフレームを拒否するものとします。クラス3では、フレームがドロップされます。
4. When an Exchange is created between 2 Ports for IP/ARP data, it remains active while the ports are logged in with each other. An Exchange SHALL NOT transfer Sequence Initiative (SI). Broadcasts and ELS commands may use short lived Exchanges.
4. IP/ARPデータの2つのポート間で交換が作成されると、ポートが互いにログインしている間、アクティブのままです。交換はシーケンスイニシアチブ（SI）を転送してはなりません。ブロードキャストとELSコマンドは、短命の交換を使用する場合があります。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| ARP Server Support | MUST NOT | 1 |
| Response to ARP requests | REQUIRED | 2 |
| Class of Service for ARP requests | Class 3 | 3 |
| Class of Service for ARP replies | Class | 4 |
| | 1, 2, or 3 | |
| Response to InARP requests | OPTIONAL | |
| Class of Service for InARP requests/replies | Class | |
| | 1, 2 or 3 | 5 |
+--------------------------------------------------------------------+
Notes:
ノート：
1. Well-known Address FFFFFC is not used for ARP requests. Frames from Well-known address FFFFFC are not considered to be ARP frames. Broadcast support is REQUIRED for ARP.
1. よく知られているアドレスFFFFFCは、ARPリクエストには使用されません。よく知られているアドレスFFFFFCのフレームは、ARPフレームとは見なされません。ARPにはブロードキャストサポートが必要です。
2. The IP Address is mapped to a specific MAC address with ARP.
2. IPアドレスは、ARPを使用して特定のMacアドレスにマッピングされます。
3. An ARP request is a Broadcast Sequence, therefore Class 3 is always used.
3. ARP要求はブロードキャストシーケンスであるため、クラス3が常に使用されます。
4. An ARP reply is a normal Sequence, thus the administrator configured class of service is used.
4. ARP応答は通常のシーケンスであるため、管理者が設定されたサービスのクラスが使用されます。
5. An InARP Request or Reply is a normal Sequence, thus an administrator configured class of service is used.
5. INARPRIECTリクエストまたは返信は通常のシーケンスであるため、管理者が設定されたサービスクラスが使用されます。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Class of service for ELS commands / responses | Class | |
| | 1,2 or 3 | 1 |
| Explicit N-Port Login | REQUIRED | |
| Explicit F-Port Login | REQUIRED | |
| FLOGI ELS command | REQUIRED | |
| PLOGI ELS command | REQUIRED | |
| ADISC ELS command | REQUIRED | |
| PDISC ELS command | OPTIONAL | 2 |
| FAN ELS command | REQUIRED | 5 |
| LOGO ELS command | REQUIRED | |
| FARP-REQ/FARP-REPLY ELS commands | REQUIRED | 3 |
| Other ELS command support | OPTIONAL | 4 |
+-----------------------------------------------+------------+-------+
Notes:
ノート：
1. The administrator configured class of service is used.
1. 管理者構成されたサービスのクラスが使用されます。
2. PDISC shall not be used as a Requester; ADISC shall be used instead. As a Responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other specifications.
2. PDISCは要求者として使用してはなりません。代わりにADISCを使用するものとします。応答者として、実装は、他の仕様との互換性のためにAdiscとPDISCの両方に応答する必要がある場合があります。
3. Responder Action - FARP-REPLY and/or Port Login - for a successful MATCH_WW_PN is always REQUIRED. Support for all other match Address Codes Points is a silent behavior from the Responder is valid when it is not supported. Recipients of the FARP-REQ ELS shall not issue a Service Reject (LS_RJT) if FARP is not supported.
3. レスポンダーアクション - FARP -REPLYおよび/またはポートログイン - 成功したMATCH_WW_PNのために常に必要です。他のすべてのマッチアドレスコードポイントのサポートは、サポートされていない場合に有効であるレスポンダーからのサイレントな動作です。FARP-REQ ELSの受信者は、FARPがサポートされていない場合、サービス拒否（LS_RJT）を発行してはなりません。
4. If other ELS commands are received an LS_RJT may be sent. NOP is not required by this specification, and shall not be used as a mechanism to terminate exchanges.
4. 他のELSコマンドが受信された場合、LS_RJTが送信される場合があります。NOPはこの仕様では要求されず、交換を終了するメカニズムとして使用してはなりません。
5. Required for FL_Ports
5. fl_portsに必要です
Unless explicitly noted here, a compliant implementation shall use the login parameters as described in [4].
ここで明示的に記載されていない限り、[4]で説明されているように、準拠の実装はログインパラメーターを使用するものとします。
- FC-PH Version, lowest version may be 0x09 to indicate 'minimum 4.3'. - Can't use BB_Credit=0 for N_Port on a switched Fabric (F_Port).
- FC-PHバージョン、最低バージョンは「最小4.3」を示すために0x09です。-switched生地（f_port）のn_portにbb_credit = 0を使用できません。
- FC-PH Version, lowest version may be 0x09 to indicate 'minimum 4.3'. - Can't use BB_Credit=0 for N_Port in a Point-to-Point configuration
- FC-PHバージョン、最低バージョンは「最小4.3」を示すために0x09です。 - ポイントツーポイント構成でn_portにbb_credit = 0を使用できません
- Random Relative Offset is optional.
- ランダムな相対オフセットはオプションです。
- Note that the 'Receive Data Field Size' fields specified in the PLOGI represent both optional headers and payload.
- Plogiで指定されている「データフィールドサイズの受信」フィールドは、オプションのヘッダーとペイロードの両方を表していることに注意してください。
- The MAC Address can therefore be extracted from the 6 lower bytes of the WW_PN field (when the IEEE 48-bit Identifier format is chosen as the NAA) during PLOGI or ACC payload exchanged during Fibre Channel Login [2].
- したがって、MACアドレスは、ww_pnフィールドの6バイト（IEEE 48ビット識別子形式がNAAとして選択される場合）から抽出できます。
- The MAC Address can also be extracted from the WW_PN field in the Network_Header during ADISC (and ADISC ACC), or PDISC (and PDISC ACC).
- MACアドレスは、Adisc（およびAdisc Acc）またはPDISC（およびPDISC ACC）中にNetwork_Headerのww_pnフィールドから抽出することもできます。
- Discard error policy only.
- エラーポリシーのみを破棄します。
IP and ARP do not introduce any new security concerns beyond what already exists within the Fibre Channel Protocols and Technology. Therefore IP and ARP related Security does not require special consideration in this document.
IPとARPは、ファイバーチャネルプロトコルとテクノロジー内に既に存在するものを超えて、新しいセキュリティの懸念を導入しません。したがって、IPおよびARP関連のセキュリティでは、このドキュメントでは特別な検討を必要としません。
FC Standards [11] specify a Security Key Server (independent of IP and ARP) as an optional service. However, there are no known implementations of this server yet. Also, the previously defined [2] use of a Security Header has been discontinued [11].
FC標準[11]オプションのサービスとして、セキュリティキーサーバー（IPとARPに依存しない）を指定します。ただし、このサーバーの既知の実装はまだありません。また、以前に定義された[2]セキュリティヘッダーの使用は中止されました[11]。
This specification is based on FCA IP Profile, Version 3.3. The FCA IP Profile was a joint work of the Fibre Channel Association (FCA) vendor community. The following organizations or individuals have contributed to the creation of the FCA IP Profile: Adaptec, Ancor, Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar, Gadzoox, Hewlett Packard, Interphase, Jaycor, McData, Migration Associates, Orca Systems, Prisa, Q-Logic, Symbios, Systran, Tektronix, Univ. of Minnesota, Univ. of New Hamshire. Jon Infante from Emulex deserves special mention for his contributions to the FARP Protocol. The authors extend their thanks to all who provided comments and especially to Lansing Sloan from LLNL for his detailed comments.
この仕様は、FCA IPプロファイルバージョン3.3に基づいています。FCA IPプロファイルは、Fiber Channel Association（FCA）ベンダーコミュニティの共同作業でした。以下の組織または個人は、FCA IPプロファイルの作成に貢献しています：Adaptec、Ancor、Brocade、Clariion、Crossroads、Emf Associates、Emulex、Finisar、Gadzoox、Hewlett Packard、Interphase、Jaycor、McData、Migration Assionates、Orca Systems、Prisa、Q-Logic、Symbios、Systran、Tektronix、Univ。ミネソタ州の大学。ニューハムシャーの。EmulexのJon Infanteは、FARPプロトコルへの貢献について特別な言及に値します。著者は、コメントを提供したすべての人に感謝し、特に彼の詳細なコメントについてLLNLのLansing Sloanに感謝します。
[1] FCA IP Profile, Revision 3.3, May 15, 1997
[1] FCA IPプロファイル、リビジョン3.3、1997年5月15日
[2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI X3.230-1994
[2] ファイバーチャネル物理およびシグナル伝達インターフェイス（FC-PH）、ANSI X3.230-1994
[3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1996
[3] ファイバーチャネルリンクカプセル化（FC-LE）、リビジョン1.1、1996年6月26日
[4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.7, August 12, 1997
[4] ファイバーチャネルファブリックループアタッチメント（FC-FLA）、Rev。2.7、1997年8月12日
[5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), Rev. 2.1, September 22, 1997
[5] ファイバーチャネルプライベートループSCSIダイレクトアタッチ（FC-PLDA）、Rev。2.1、1997年9月22日
[6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), Rev. 7.4, ANSI X3.297-1996
[6] ファイバーチャネル物理およびシグナル伝達インターフェイス2（FC-PH-2）、Rev。7.4、ANSI X3.297-1996
[7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996
[7] ファイバーチャネル仲裁ループ（FC-AL）、ANSI X3.272-1996
[8] Postel, J. and J. Reynolds, "A standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[8] Postel、J。およびJ. Reynolds、「IEEE 802ネットワークを介したIPデータグラムの送信の標準」、STD 43、RFC 1042、1988年2月。
[9] Plummer, D. "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.
[9] Plummer、D。
[10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995
[10] FCSI IPプロファイル、FCSI-202、リビジョン2.1、1995年9月8日
[11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), Rev. 9.3, ANSI X3.303-199x
[11] ファイバーチャネル物理およびシグナル伝達インターフェイス-3（FC-PH-3）、Rev。9.3、ANSI X3.303-199X
[12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", Ancot Corporation
[12] ファイバーチャンネル - 基本、「ゲイリーR.スティーブンスとヤンV.デデク」、アンコットコーポレーション
[13] Fibre Channel -Gigabit Communications and I/O for Computers Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2
[13] ファイバーチャネル-Gigabit CommunicationsおよびI/Oコンピューターネットワーク「Alan Benner」、McGraw-Hill、1996、ISBN 0-07-005669-2
[14] Fibre Channel Generic Services -2 (FC-GS-2), Rev. 5.2 X3.288-199x
[14] ファイバーチャネルジェネリックサービス-2（FC-GS-2）、Rev。5.2x3.288-199x
[15] Bradley, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, January 1992.
[15] Bradley、T。およびC. Brown、「逆住所解像度プロトコル」、RFC 1293、1992年1月。
[16] Bradley, T., Brown, C. and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, August 1992.
[16] Bradley、T.、Brown、C。and A. Malis、「逆住所解像度プロトコル」、RFC 2390、1992年8月。
[17] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[17] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[18] The Fibre Channel Consultant: A Comprehensive Introduction, "Robert W. Kembel", Northwest Learning Associates, 1998
[18] ファイバーチャンネルコンサルタント：包括的な紹介、「ロバートW.ケンベル」、ノースウエストラーニングアソシエイツ、1998年
[19] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[20] Narten, T. and C. Burton, "A Caution on The Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
[20] Narten、T。およびC. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、RFC 2469、1998年12月。
Murali Rajagopal Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
Murali Rajagopal Gadzoox Networks、Inc。711 Kimberly Avenue、Suite 100 Placentia、CA 92870
Phone: +1 714 577 6805
Fax: +1 714 524 8508
EMail: murali@gadzoox.com
Raj Bhagwat Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
Raj Bhagwat Gadzoox Networks、Inc。711 Kimberly Avenue、Suite 100 Placentia、CA 92870
Phone: +1 714 577 6806
Fax: +1 714 524 8508
EMail: raj@gadzoox.com
Wayne Rickard Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
ウェインリッカードガドーズネットワークス、インク711キンバリーアベニュー、スイート100プラセンティア、カリフォルニア92870
Phone: +1 714 577 6803
Fax: +1 714 524 8508
EMail: wayne@gadzoox.com
Appendix A: Additional Matching Mechanisms in FARP
付録A：FARPの追加マッチングメカニズム
Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes:
セクション5では、FARPプロトコルを使用して、ww_pnとport_idの間のFCレイヤーマッピングについて説明しました。この付録では、アドレスマッチングに関する他のオプションの基準について説明し、以下を含みます。
- WW_NN
- ww_nn
- WW_PN & WW_NN at the same time
- ww_pn＆ww_nn同時に
- IPv4
- IPv4
- IPv4 & WW_PN at the same time
- 同時にIPv4とww_pn
- IPv4 & WW_NN at the same time
- IPv4とww_nn同時に
- IPv4 & WW_PN & WW_NN at the same time
- 同時にIPv4＆ww_pn＆ww_nn
Depending on the Match Address Code Points, the FARP protocol fundamentally resolves three main types of addresses to Port_IDs and is described in table below.
一致アドレスコードポイントに応じて、FARPプロトコルはPORT_IDSの3つの主要なアドレスを根本的に解決し、以下の表に説明します。
- For Match Address Code Point b'001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder.
- マッチアドレスの場合、コードポイントB'001 '：ww_pn名フィールドは、ww_pn名をport_idsに解決するために使用されます。WW_NNおよびIPアドレスフィールドはこれらのコードポイントでは使用されず、リクエスターまたはリクエスターとレスポンダーによって「0」または有効なアドレスのいずれかに設定されます。
- For Match Address Code Point b'010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder.
- 一致アドレスの場合、コードポイントB'010 '：ww_nn名フィールドは、ww_nn名をport_idsに解決するために使用されます。ww_pnおよびIPアドレスフィールドはこれらのコードポイントでは使用されず、リクエスターまたはリクエスターとレスポンダーによる「0」または有効なアドレスのいずれかに設定されます。
- For Match Address Code Point b'100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either ' 0' or valid addresses by Requester or Requester and Responder.
- 一致アドレスの場合、コードポイントB'100 '：IPv4フィールドは、port_idsのIPv4アドレスを解決するために使用されます。ww_pnおよびww_nnフィールドは、これらのコードポイントでは使用されず、requesterまたはrequester and Responderによる「0」または有効なアドレスのいずれかに設定されます。
- For all other Match Address Code Points b'011', b'101',b'110', b'111', depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses.
- 他のすべての一致アドレスコードポイントb'011 '、b'101'、b'110 '、b'111'について、セットビットに応じて、1つ以上のアドレスが共同でport_idに解決されます。以下の表を参照してください。フィールドが使用されない場合、それらは「0」または有効なアドレスのいずれかに設定されます。
The Responder Flags remain the same as before. Note that there can be utmost one FARP-REPLY per FARP-REQ.
レスポンダーフラグは以前と同じままです。FARP-REQごとに最大のFARP-Replyが存在する可能性があることに注意してください。
Tables showing FARP-REQ and FARP-REPLY and address fields setting are given below:
FARP-REQとFARP-REPLYを示すテーブルとアドレスフィールド設定を以下に示します。
+--------------------------------------------------------------------+
| Match Address Code Points |
+--------------------------------------------------------------------+
| LSBits| Bit name | Action |
+-------+--------------------+---------------------------------------+
| 000 | Reserved | |
+-------+--------------------+---------------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-------+--------------------+---------------------------------------+
| 010 | MATCH_WW_NN | If 'WW_NN of Responder' = |
| | | Node's WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' = |
| | | Node's WW_PN & WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = |
| | | Node's IPv4 Address then respond |
+-------+--------------------+---------------------------------------+
| 101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = |
| | | Node's WW_PN and IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Node's WW_NN & IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Nodes' WW_PN & WW_NN & IPv4 |
| | | then respond |
+-------+--------------------+---------------------------------------+
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x54-00-00-00 | 4 | Request Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 |Response Action to be taken|
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 | Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; |
| | |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL ;Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x55-00-00-00 | 4 |Reply Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 |Supplied by Responder |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; Supplied by |
| | |Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL; Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
Appendix B: InARP
付録B：INARP
Inverse ARP (InARP) is a mechanism described in RFC 1293/2390 [15, 16], which is useful when a node desires to know the protocol address of a target node whose hardware address is known. Situations where this could occur are described in [15, 16]. The motivation for using InARP in FC is to allow a node to learn the IP address of another node with which it has performed a Port Login (PLOGI). PLOGI is a normal FC process that happens between nodes, independent of this standard. PLOGI makes it possible for a node to discover the WW_PN and the Port_ID of the other node but not its IP address. A node in this way may potentially obtain the IP address of all nodes with which it can PLOGI.
Inverse ARP（INARP）は、RFC 1293/2390 [15、16]に記載されているメカニズムです。これは、ノードがハードウェアアドレスが既知のターゲットノードのプロトコルアドレスを知りたい場合に役立ちます。これが発生する可能性のある状況は[15、16]で説明されています。FCでINARPを使用する動機は、ノードがポートログイン（PLOGI）を実行した別のノードのIPアドレスを学習できるようにすることです。Plogiは、この標準とは無関係に、ノード間で発生する通常のFCプロセスです。Plogiは、ノードがIPアドレスではなく、他のノードのww_pnとport_idを発見できるようにします。この方法でのノードは、Plogiが可能なすべてのノードのIPアドレスを潜在的に取得する場合があります。
Note that the use of the InARP mechanism can result in resolving all WW_PN to IP addresses and ARP may no longer be required. This can be beneficially applied in cases where a particular FC topology makes it inefficient to send out an ARP broadcast.
INARPメカニズムを使用すると、すべてのww_pnがIPアドレスに解決され、ARPが不要になる可能性があることに注意してください。これは、特定のFCトポロジがARPブロードキャストを送信するのが非効率的である場合に有益に適用できます。
InARP uses the same ARP Packet format but with different 'Op Codes', one for InARP Request and another for InARP Reply.
INARPは同じARPパケット形式を使用しますが、異なる「OPコード」を使用します。1つはINARPリクエスト用で、もう1つはARRPの返信になります。
The InARP protocol operation is very simple. The requesting node fills the hardware address (WW_PN) of the target device and sets the protocol address to 0x00-00-00-00. Because, the request is sent to a node whose WW_PN and Port_ID are known, there is no need for a broadcast. The target node fills in its Protocol address (IP address in this case) and sends an InARP Reply back to the sender. A node may collect, all such WW_PN and IP addresses pairs in a similar way.
INARPプロトコル操作は非常に簡単です。リクエストノードは、ターゲットデバイスのハードウェアアドレス（ww_pn）を埋め、プロトコルアドレスを0x00-00-00-00に設定します。なぜなら、リクエストはww_pnとport_idが知られているノードに送信されるため、ブロードキャストの必要はないからです。ターゲットノードは、そのプロトコルアドレス（この場合はIPアドレス）に記入され、送信者にARRPの返信を送信します。ノードが収集される場合があります。このようなすべてのww_pnおよびIPアドレスは、同様の方法でペアになります。
Since the InARP protocol uses the same packet format as the ARP protocol, much of the discussion on ARP formats given in Section 4 applies here.
INARPプロトコルはARPプロトコルと同じパケット形式を使用するため、セクション4に示されているARP形式に関する議論の多くはここに適用されます。
The InARP is 28-bytes long in this application and uses two packet types: Request and Reply. Like ARP, the InARP Packet fields are common to both InARP Requests and InARP Replies.
このアプリケーションでは、ARPが28バイトの長さで、リクエストと返信の2つのパケットタイプを使用します。ARPと同様に、INARPパケットフィールドは、INARPリクエストとINARP応答の両方に共通しています。
InARP Request and Reply Packets are encapsulated in a single frame FC Sequence much like ARP. Compliant InARP Request and Reply FC Sequences SHALL include Network_Headers.
INARPリクエストと返信パケットは、ARPによく似た単一のフレームFCシーケンスにカプセル化されています。準拠のINARPリクエストと応答FCシーケンスには、Network_Headersを含めるものとします。
The 'HW Type' field SHALL be set to 0x00-01.
「HWタイプ」フィールドは0x00-01に設定する必要があります。
The 'Protocol' field SHALL be set to 0x08-00 indicating IP protocol.
「プロトコル」フィールドは、IPプロトコルを示す0x08-00に設定するものとします。
The 'HW Addr Length' field SHALL be set to 0x06 indicating 6-bytes of HW address.
「HW addr length」フィールドは、HWアドレスの6バイトを示す0x06に設定する必要があります。
The 'Protocol Addr Length' field SHALL be set to 0x04 indicating 4-bytes of IP address.
「プロトコルADDR長」フィールドは、IPアドレスの4バイトを示す0x04に設定する必要があります。
The 'Operation' Code field SHALL be set as follows:
「操作」コードフィールドは、次のように設定するものとします。
0x00-08 for InARP Request 0x00-09 for InARP Reply
INARP要求の0x00-08 INARP応答の0x00-09
The 'HW Addr of Sender' field SHALL be the 6-byte IEEE MAC address of the Requester (InARP Request) or Responder (InARP Reply).
「送信者のHWアドオン」フィールドは、リクエスター（INARPリクエスト）またはレスポンダー（INARP REPLY）の6バイトIEEE MACアドレスでなければなりません。
The 'Protocol Addr of Sender' field SHALL be the 4-byte IP address of the Requester (InARP Request) or Responder (InARP Reply).
「送信者のプロトコルADDR」フィールドは、リクエスター（INARPリクエスト）またはレスポンダー（INARP REPLY）の4バイトIPアドレスでなければなりません。
The 'HW Addr of Target' field SHALL be set to the 6-byte MAC address of the Responder in an InARP Request and to the 6-byte MAC address of the Requester in an InARP Reply.
「ターゲットのHW ADDR」フィールドは、ARRPリクエストでの6バイトのMACアドレスのResponderのアドレスと、ARPREPECTERの6バイトMACアドレスに設定するものとします。
The 'Protocol Addr of Target' field SHALL be set to 0x00-00-00-00 in an InARP Request and to the 4-byte IP address of the Requester in an InARP Reply.
「ターゲットのプロトコル」フィールドは、ARRPリクエストで0x00-00-00-00に設定され、ARPLEFECTERの4バイトIPアドレスに設定するものとします。
Support for InARP is OPTIONAL. If a node does not support InARP and it receives an InARP Request message then a silent behavior is specified.
INARPのサポートはオプションです。ノードがinarpをサポートせず、inarpリクエストメッセージを受信した場合、サイレント動作が指定されます。
APPENDIX C: Some Informal Mechanisms for FC Layer Mappings
付録C：FC層マッピングのいくつかの非公式メカニズム
Each method SHALL have some check to ensure PLOGI has completed successfully before data is sent. A related concern in large networks is limiting concurrent logins to only those ports with active IP traffic.
各方法では、データが送信される前にPlogiが正常に完了したことを確認するためのチェックがあります。大規模なネットワークに関連する懸念は、同時ログインをアクティブなIPトラフィックを持つポートのみに制限することです。
This method insulates the level performing Login from the level interpreting ARP. It is more accommodating of non-ARP mechanisms for building the FC-layer mapping table.
この方法は、ARPを解釈するレベルからログインを実行するレベルを隔離します。FC層マッピングテーブルを構築するための非ARPメカニズムをより収容できます。
1. Broadcast messages that carry a Network_Header contain the S_ID on the FC-header and WW_PN in the Network-Header. Caching this information provides a correlation of Port_ID to WW_PN. If the received Broadcast message is compliant with this specification, the WW_PN will contain the MAC Address.
1. Network_Headerを運ぶブロードキャストメッセージには、FC-HeaderのS_IDとNetwork-Headerのww_pnが含まれています。この情報をキャッシュすると、port_idとww_pnの相関があります。受信したブロードキャストメッセージがこの仕様に準拠している場合、ww_pnにはMacアドレスが含まれます。
2. The WW_PN is "available" if Login has been performed to the Port_ID and flagged. If Login has not been performed, the WW_PN is "unavailable".
2. ww_pnは、ログインがport_idに実行され、フラグが付けられた場合、「利用可能」です。ログインが実行されていない場合、ww_pnは「利用できません」。
3. If an outbound packet is destined for a port that is "unavailable", the cached information (from broadcast) is used to look up the Port_ID.
3. アウトバウンドパケットが「利用できない」ポート用に運命づけられている場合、キャッシュされた情報（ブロードキャストから）を使用してPORT_IDを検索します。
4. After sending an ELS PLOGI command (Port Login) to the Port (from a higher level entity at the host), waiting for an outbound packet before sending this Port Login conserves resources for only those ports which wish to establish communication.
4. Els Plogiコマンド（ポートログイン）をポート（ホストのより高いレベルのエンティティから）に送信した後、このポートログインを送信する前に、通信を確立したいポートのみにリソースを保存します。
5. After Port Login completes (ACC received), the outbound packet can be forwarded. At this point in time, both ends have the necessary information to complete their <IP address, MAC Address, Port_ID> association.
5. ポートログインが完了すると（ACCが受信）、アウトバウンドパケットを転送できます。この時点で、両端には、<IPアドレス、MACアドレス、PORT_ID>協会を完了するために必要な情報があります。
This method performs Login sooner by parsing ARP before passing it up to higher levels for IP/MAC Address correlation. It requires a low-level awareness of the IP address, and is therefore protocol-specific.
このメソッドは、ARPを解析することにより、IP/MACアドレスの相関についてより高いレベルに渡すことにより、ログインをより早く実行します。IPアドレスに対する低レベルの認識が必要であるため、プロトコル固有です。
1. When an ARP Broadcast Message is received, the S_ID is extracted from the FC-header and the corresponding Network_Source_Address from the Network_Header.
1. ARPブロードキャストメッセージが受信されると、S_IDはFC-Headerから抽出され、Network_Headerから対応するNetwork_Source_Addressが抽出されます。
2. The ARP payload is parsed to determine if (a) this host is the target of the ARP request (Target IP Address match), and (b) if this host is currently logged in with the port (Port_ID = S_ID) originating the ARP broadcast.
2. ARPペイロードは、（a）このホストがARPリクエストのターゲット（ターゲットIPアドレスマッチ）であるかどうか、（b）このホストが現在ARPブロードキャストを発信するポート（PORT_ID = S_ID）で現在ログインしているかどうかを判断するために解析されます。。
3. The ARP is passed to a higher level for ARP Response generation.
3. ARPは、ARP応答生成のためにより高いレベルに渡されます。
4. If a Port Login is required, an ELS PLOGI command (Port Login) is sent immediately to the Port originating the ARP Broadcast.
4. ポートログインが必要な場合、ARPブロードキャストを発信するポートにELS Plogiコマンド（ポートログイン）がすぐに送信されます。
5. After Port Login completes, an ARP response can be forwarded. Note that there are two possible scenarios:
5. ポートログインが完了した後、ARP応答を転送できます。可能なシナリオが2つあることに注意してください。
- The ACC to PLOGI returns before the ARP reply is processed and the ARP Reply is immediately forwarded. - The ARP reply is delayed, waiting for ACC (successful Login).
- ARPの返信が処理され、ARPの返信がすぐに転送される前に、PlogiへのACCが戻ります。-ARP返信は遅れており、ACC（ログインの成功）を待っています。
6. At this point in time, both ends have the necessary information to complete their <IP address, MAC Address, Port_ID> association.
6. この時点で、両端には、<IPアドレス、MACアドレス、PORT_ID>協会を完了するために必要な情報があります。
In Fibre Channel topologies with a limited number of ports, it may be efficient to unconditionally Login to each port. This method is discouraged in fabric and public loop environments.
限られた数のポートを持つファイバーチャネルトポロジでは、各ポートに無条件にログインするのが効率的かもしれません。この方法は、ファブリックおよびパブリックループ環境では阻止されています。
After Port Login completes, the MAC Address to Port_ID Address tables can be constructed.
ポートログインが完了した後、MacアドレスへのPORT_IDアドレステーブルを構築できます。
In some loop environments with a limited number of ports, a static mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be maintained. The FC layer will always know the destination Port_ID based on the table. The table is typically downloaded into the driver at configuration time. This method scales poorly, and is therefore not recommended.
限られた数のポートを備えた一部のループ環境では、MacアドレスからPORT_ID（D_IDまたはAL_PA）への静的マッピングが維持される場合があります。FCレイヤーは、テーブルに基づいて常に宛先PORT_IDを知ります。テーブルは通常、構成時間にドライバーにダウンロードされます。この方法はスケールが不十分であるため、推奨されません。
Appendix D: FC Layer Address Validation
付録D：FCレイヤーアドレス検証
At all times, the <WW_PN, Port_ID> mapping MUST be valid before use. There are many events that can invalidate this mapping. The following discussion addresses conditions when such a validation is required.
常に、<ww_pn、port_id>マッピングは使用する前に有効でなければなりません。このマッピングを無効にすることができる多くのイベントがあります。次の議論は、そのような検証が必要な場合の条件に対処します。
After a FC link interruption occurs, the Port_ID of a port may change. After the interruption, the Port_IDs of all other ports that have previously performed PLOGI (N_Port Login) with this port may have changed, and its own Port_ID may have changed.
FCリンクの中断が発生した後、ポートのPORT_IDが変更される場合があります。中断後、このポートで以前にPlogi（N_PORTログイン）を実行した他のすべてのポートのPORT_IDSが変更された可能性があり、独自のPORT_IDが変更された可能性があります。
Because of this, address validation is required after a LIP in a loop topology [7] or after NOS/OLS in a point-to-point topology [6].
このため、ループトポロジのリップ[7]またはポイントツーポイントトポロジー[6]のNOS/OLSの後にアドレス検証が必要です。
Port_IDs will not change as a result of Link Reset (LR),thus address validation is not required.
PORT_IDSはリンクリセット（LR）の結果として変更されないため、アドレス検証は必要ありません。
In addition to actively validating devices after a link interruption, if a port receives any FC-4 data frames (other than broadcast frames), from a port that is not currently logged in, then it shall send an explicit Extended Link Service (ELS) Request logout (LOGO) command to that port.
リンクの中断後にデバイスを積極的に検証することに加えて、ポートが現在ログインしていないポートからFC-4データフレーム（ブロードキャストフレーム以外）を受信した場合、明示的な拡張リンクサービス（ELS）を送信するものとします。ログアウト（ロゴ）コマンドをそのポートにリクエストします。
ELS commands (Requests and Replies) are used by an N_Port to solicit a destination port (F_Port or N_Port) to perform some link-level function or service.) The LOGO Request is used to request invalidation of the service parameters and Port_ID of the recipient N_Port.
ELSコマンド（リクエストと返信）は、N_PORTによって使用され、宛先ポート（F_PORTまたはN_PORT）を募集してリンクレベルの関数またはサービスを実行します。）ロゴリクエストは、レシピエントのサービスパラメーターとPORT_IDの無効化を要求するために使用されます。n_port。
The level of initialization and subsequent validation and recovery reported to the upper (FC-4) layers is implementation-specific.
上部（FC-4）層に報告された初期化とその後の検証と回復のレベルは、実装固有です。
In general, an explicit Logout (LOGO) SHALL be sent whenever the FC-Layer mapping between the Port_ID and WW_PN of a remote port is removed.
一般に、リモートポートのPORT_IDとWW_PNの間のFCレイヤーマッピングが削除されるたびに、明示的なログアウト（ロゴ）が送信されます。
The effect of power-up or re-boot on the mapping tables is outside the scope of this specification.
マッピングテーブルに対するパワーアップまたは再起動の効果は、この仕様の範囲外です。
No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each port and after a NOS/OLS, each port must perform a PLOGI [2].
LR後に検証は必要ありません。ポイントツーポイントトポロジでは、NOS/OLSは各ポートの暗黙的なログアウトを引き起こし、NOS/OLSの後、各ポートがPlogiを実行する必要があります[2]。
After a LIP, a port SHALL not transmit any link data to another port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC. (See Appendix G.)
リップの後、ポートは、他のポートのアドレスが検証されるまで、リンクデータを別のポートに送信してはなりません。検証は、ADISCまたはPDISCのいずれかを完了することで構成されています。（付録Gを参照してください。）
ADISC (Address Discovery) is an ELS command for discovering the hard addresses - the 24-bit identifier- of NL_Ports [5], [6].
ADISC（アドレス発見）は、NL_PORTS [5]、[6]のハードアドレス（24ビット識別子）を発見するためのELSコマンドです。
PDISC (Discover Port) is an ELS command for exchanging service parameters without affecting Login state [5], [6].
PDISC（発見ポート）は、ログイン状態[5]、[6]に影響を与えることなく、サービスパラメーターを交換するためのELSコマンドです。
As a requester, this specification prohibits PDISC and requires ADISC.
要求者として、この仕様はPDISCを禁止し、ADISCが必要です。
As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
応答者として、実装は、他のFC仕様との互換性のためにADISCとPDISCの両方に応答する必要がある場合があります。
If the three addresses, Port_ID, WW_PN, WW_NN, exactly match the values prior to the LIP, then any active exchanges may continue.
3つのアドレス、port_id、ww_pn、ww_nnが、唇の前に値と正確に一致する場合、アクティブな交換は継続する場合があります。
If any of the three addresses have changed, then the node must be explicitly Logged out [4], [5].
3つのアドレスのいずれかが変更された場合、ノードは明示的にログアウトする必要があります[4]、[5]。
If a port's N_Port ID changes after a LIP, then all active Port-ID to WW_PN mappings at this port must be explicitly Logged out.
ポートのN_PORT IDがリップの後に変更された場合、このポートでのすべてのアクティブなポートIDへのすべてのアクティブポートIDは、明示的にログアウトする必要があります。
A FAN (Fabric Address Notification) ELS command is sent by the fabric to all known previously logged in ports following an initialization event. Therefore, after a LIP, hosts may wait for this notification to arrive or they may perform a FLOGI.
ファン（ファブリックアドレス通知）ELSコマンドは、ファブリックから、初期化イベントに続いて以前に記録されていたすべてのポートに記録されたすべてに送信されます。したがって、唇の後、ホストはこの通知が到着するのを待つか、フロギを実行する場合があります。
If the WW_PN and WW_NN of the fabric FL_Port contained in the FAN ELS or FLOGI response exactly match the values before the LIP, and if the AL_PA obtained by the port is the same as the one before the LIP, then the port may resume all exchanges. If not, then FLOGI (Fabric Login) must be performed with the fabric and all nodes must be explicitly Logged out.
ファンELSまたはFLOGI応答に含まれるファブリックFL_PORTのWW_PNとWW_NNが唇の前の値と正確に一致し、ポートで取得したAL_PAが唇の前のものと同じ場合、ポートはすべての取引所を再開できます。。そうでない場合は、Flogi（ファブリックログイン）をファブリックで実行する必要があり、すべてのノードを明示的にログアウトする必要があります。
A public loop device will have to perform the private loop authentication to any nodes on the local loop which have an Area + Domain Address == 0x00-00-XX
パブリックループデバイスは、エリアドメインアドレスを持つローカルループ上の任意のノードに対してプライベートループ認証を実行する必要があります== 0x00-00-xx
No validation is required after LR (link reset).
LR（リンクリセット）後に検証は必要ありません。
After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID of the port, the WW_PN of the fabric, and the WW_NN of the fabric are the same as before the NOS/OLS, then the port may resume all exchanges. If not, all nodes must be explicitly, Logged out [2].
NOS/OLSの後、ポートはFlogiを実行する必要があります。フロギの後、ポートのs_id、ファブリックのww_pn、およびファブリックのww_nnがnos/olsの前と同じ場合、ポートはすべての交換を再開する場合があります。そうでない場合、すべてのノードを明示的にログアウトする必要があります[2]。
APPENDIX E: Fibre Channel Overview
付録E：ファイバーチャネルの概要
The FC Standard [2] defines 5 "levels" (not layers) for its protocol description: FC-0, FC-1, FC-2, FC-3, and FC-4. The first three levels (FC-0, FC-1, FC-2) are largely concerned with the physical formatting and control aspects of the protocol. FC-3 has been architected to provide a place holder for functions that might need to be performed after the upper layer protocol has requested the transmission of an information unit, but before FC-2 is asked to deliver that piece of information by using a sequence of frames [18]. At this time, no FC-3 functions have been defined. FC-4 is meant for supporting profiles of Upper Layer Protocols (ULP) such as IP and Small Computer System Interface (SCSI), and supports a relatively small set compared to LAN protocols such as IEEE 802.3.
FC標準[2]は、そのプロトコルの説明に5 "レベル"（層ではない）を定義します：FC-0、FC-1、FC-2、FC-3、およびFC-4。最初の3つのレベル（FC-0、FC-1、FC-2）は、プロトコルの物理的な書式と制御の側面に大きく関係しています。FC-3は、上層層プロトコルが情報ユニットの送信を要求した後に実行する必要がある機能の場所ホルダーを提供するために設計されていますが、FC-2がシーケンスを使用してその情報を提供するように求められる前にフレームの[18]。現時点では、FC-3関数は定義されていません。FC-4は、IPやSmall Computer System Interface（SCSI）などの上層プロトコル（ULP）のプロファイルをサポートするためのものであり、IEEE 802.3などのLANプロトコルと比較して比較的小さなセットをサポートしています。
FC devices are called "Nodes", each of which has at least one "Port" to connect to other ports. A Node may be a workstation, a disk drive or disk array, a camera, a display unit, etc. A "Link" is two unidirectional paths flowing in opposite directions and connecting two Ports within adjacent Nodes.
FCデバイスは「ノード」と呼ばれ、それぞれに他のポートに接続するための少なくとも1つの「ポート」があります。ノードは、ワークステーション、ディスクドライブまたはディスクアレイ、カメラ、ディスプレイユニットなどです。「リンク」は、反対方向に流れ、隣接するノード内の2つのポートを接続する2つの単方向パスです。
FC Nodes communicate using higher layer protocols such as SCSI and IP and are configured to operate using Point-to-Point, Private Loop, Public Loop (attachment to a Fabric), or Fabric network topologies.
FCノードは、SCSIやIPなどの高層プロトコルを使用して通信し、ポイントツーポイント、プライベートループ、パブリックループ（ファブリックへのアタッチメント）、またはファブリックネットワークトポロジを使用して動作するように構成されています。
The point-to-point is the simplest of the four topologies, where only two nodes communicate with each other. The private loop may connect a number of devices (max 126) in a logical ring much like Token Ring, and is distinguished from a public loop by the absence of a Fabric Node participating in the loop. The Fabric topology is a switched network where any attached node can communicate with any other. For a detail description of FC topologies refer to [18].
ポイントツーポイントは、4つのトポロジの中で最も単純なもので、2つのノードのみが互いに通信します。プライベートループは、トークンリングのような論理リングで多くのデバイス（最大126）を接続することができ、ループに参加するファブリックノードがないことにより、パブリックループと区別されます。ファブリックトポロジーは、接続されたノードが他のノードと通信できるスイッチネットワークです。FCトポロジーの詳細な説明については、[18]を参照してください。
Table below summarizes the usage of port types depending on its location [12]. Note that E-Port is not relevant to any discussion in this specification but is included below for completeness.
以下の表は、その場所[12]に応じて、ポートタイプの使用をまとめたものです。eポートは、この仕様の議論には関係ありませんが、完全性のために以下に含まれています。
+-----------+-------------+-----------------------------------------+
| Port Type | Location | Topology Associated with |
+-----------+-------------+-----------------------------------------+
| N_Port | Node | Point-to-Point or Fabric |
+-----------+-------------+-----------------------------------------+
| NL_Port | Node |In N_Port mode -Point-to-Point or Fabric |
| | |In NL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| F_Port | Fabric | Fabric |
+-----------+-------------+-----------------------------------------+
| FL_Port | Fabric | In F_Port mode - Fabric |
| | | In FL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| E_Port | Fabric | Internal Fabric Expansion |
+-----------+-------------+-----------------------------------------+
The FC 'Exchange' is a mechanism used by two FC ports to identify and manage an operation between them [18]. An Exchange is opened whenever an operation is started between two ports. The Exchange is closed when this operation ends.
FC 'Exchange'は、2つのFCポートが使用するメカニズムであり、それらの間の操作を識別および管理します[18]。2つのポート間で操作が開始されるたびに交換が開かれます。この操作が終了すると、交換は閉じられます。
The FC-4 Level specifies data units for each type of application level payload called 'Information Unit' (IU). Each protocol carried by FC has a defined size for the IU. Every operation must have at least one IU. Lower FC levels map this to a FC Sequence.
FC-4レベルは、「情報ユニット」（IU）と呼ばれるアプリケーションレベルのペイロードごとにデータユニットを指定します。FCが携帯する各プロトコルには、IUの定義済みサイズがあります。すべての操作には、少なくとも1つのIUが必要です。より低いFCレベルは、これをFCシーケンスにマッピングします。
Typically, a Sequence consists of more than one frame. Larger user data is segmented and reassembled using two methods: Sequence Count and Relative Offset [18]. With the use of Sequence Count, data blocks are sent using frames with increasing sequence counts (modulo 65536) and it is quite straightforward to detect the first frame that contains the Network_Header. When Relative Offset is used, as frames arrive, some computation is required to detect the first frame that contains the Network_Header. Sequence Count and Relative Offset field control information, is carried in the FC Header.
通常、シーケンスは複数のフレームで構成されます。より大きなユーザーデータは、シーケンスカウントと相対オフセットの2つの方法を使用してセグメント化され、再組み立てされています[18]。シーケンスカウントを使用すると、データブロックはシーケンスカウントが増加するフレームを使用して送信され（Modulo 65536）、Network_headerを含む最初のフレームを検出するのは非常に簡単です。フレームが到着すると、相対的なオフセットが使用されると、Network_Headerを含む最初のフレームを検出するためにある程度の計算が必要です。シーケンスカウントと相対的なオフセットフィールド制御情報は、FCヘッダーに掲載されています。
The FC-4 Level makes a request to FC-3 Level when it wishes it to be delivered. Currently, there are no FC-3 level defined functions, and this level simply converts the Information Unit delivery request into a 'Sequence' delivery request and passes it on to the FC-2 Level. Therefore, each FC-4 Information Unit corresponds to a FC-2 Level Sequence.
FC-4レベルは、FC-3レベルを配信したいときにリクエストを行います。現在、FC-3レベルの定義関数はありません。このレベルは、情報ユニット配信要求を「シーケンス」配信要求に変換し、FC-2レベルに渡すだけです。したがって、各FC-4情報ユニットは、FC-2レベルシーケンスに対応します。
The maximum data carried by a FC frame cannot exceed 2112-bytes [2]. Whenever, the Information Unit exceeds this value, the FC-2 breaks it into multiple frames and sends it in a sequence.
FCフレームによって運ばれる最大データは、2112バイトを超えることはできません[2]。情報ユニットがこの値を超えるたびに、FC-2はそれを複数のフレームに分割し、シーケンスで送信します。
There can be multiple Sequences within an Exchange. Sequences within an Exchange are processed sequentially. Only one Sequence is active at a time. Within an Exchange information may flow in one direction only or both. If bi-directional then one of the ports has the initiative to send the next Sequence for that Exchange. Sequence Initiative can be passed between the ports on the last frame of Sequence when control is transferred. This amounts to half-duplex behavior.
交換内に複数のシーケンスがある場合があります。交換内のシーケンスは順次処理されます。一度にアクティブなシーケンスは1つだけです。交換情報内では、一方向のみまたはその両方に流れる場合があります。双方向の場合、ポートの1つには、その交換の次のシーケンスを送信するイニシアチブがあります。制御が転送されたときに、シーケンスの最後のフレームのポート間でシーケンスイニシアチブを渡すことができます。これは半分二重挙動に相当します。
Ports may have more than one Exchange open at a time. Ports can multiplex between Exchanges. Exchanges are uniquely identified by Exchange IDs (X_ID). An Originator OX_ID and a Responder RX_ID uniquely identify an Exchange.
ポートには、一度に複数の交換が開いている場合があります。ポートは交換間で多重化できます。交換は、Exchange ID（X_ID）によって一意に識別されます。オリジネーターのox_idとレスポンダーRX_IDが交換を一意に識別します。
The FC header as shown in the diagrams below contains routing and other control information to manage Frames, Sequences, and Exchanges. The Frame-header is sent as 6 transmission words immediately following an SOF delimiter and before the Data Field.
以下の図に示すFCヘッダーには、フレーム、シーケンス、および交換を管理するためのルーティングおよびその他の制御情報が含まれています。フレームヘッダーは、SOFデリミッターの直後およびデータフィールドの直前に6つの伝送ワードとして送信されます。
D_ID and S_ID:
D_IDとS_ID：
FC uses destination address routing [12], [13]. Frame routing in a point-to-point topology is trivial.
FCは、宛先アドレスルーティング[12]、[13]を使用します。ポイントツーポイントトポロジのフレームルーティングは些細なことです。
For the Arbitrated Loop topology, with the destination NL_Port on the same AL, the source port must pick the destination port, determine its AL Physical Address, and "Open" the destination port. The frames must pass through other NL_Ports or the FL_Port on the loop between the source and destination, but these ports do not capture the frames. They simply repeat and transmit the frame. Either communicating port may "Close" the circuit.
任意のループトポロジの場合、宛先NL_portが同じALにあるため、ソースポートは宛先ポートを選択し、ALの物理アドレスを決定し、宛先ポートを「開く」必要があります。フレームは、ソースと宛先の間のループ上の他のnl_portsまたはfl_portを通過する必要がありますが、これらのポートはフレームをキャプチャしません。彼らは単にフレームを繰り返して送信します。通信ポートが回路を「閉じる」ことができます。
When the destination port is not on the same AL, the source NL_Port must open the FL_Port attached to a Fabric. Once in the Fabric, the Fabric routes the frames again to the destination.
宛先ポートが同じALにない場合、ソースNL_PORTはファブリックに接続されたFL_PORTを開く必要があります。生地に入ると、生地はフレームを再び目的地にルーティングします。
In a Fabric topology, the Fabric looks into the Frame-header, extracts the destination address (D_ID), searches its own routing tables, and sends the frame to the destination port along the path chosen. The process of choosing a path may be performed at each fabric element or switch until the F_Port attached to the destination N_Port is reached.
ファブリックトポロジーでは、ファブリックはフレームヘッダーを調べ、宛先アドレス（D_ID）を抽出し、独自のルーティングテーブルを検索し、選択したパスに沿って宛先ポートにフレームを送信します。パスを選択するプロセスは、各ファブリック要素で実行されるか、宛先N_PORTに接続されたF_PORTに到達するまで切り替えることができます。
Fibre Channel Frame Header, Network_Header, and Payload carrying IP Packet
ファイバーチャネルフレームヘッダー、Network_header、およびPayload CaringingIPパケット
+---+----------------+----------------+----------------+--------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+--------------+
|0 | R_CTL | D_ID |
+---+----------------+----------------+----------------+--------------+
|1 | CS_CTL | S_ID |
+---+----------------+----------------+----------------+--------------+
|2 | TYPE | F_CTL |
+---+----------------+----------------+----------------+--------------+
|3 | SEQ_ID | DF_CTL | SEQ_CNT |
+---+----------------+----------------+----------------+--------------+
|4 | OX_ID | RX_ID |
+---+--------+-------+----------------+----------------+--------------+
|5 | Parameter (Control or Relative Offset for Data ) |
+---+-----------------------------------------------------------------+
|6 | NAA | Network_Dest_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|7 | Network_Dest_Address (Lo order bits) |
+---+--------+-------+----------------+----------------+--------------+
|8 | NAA | Network_Src_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|9 | Network_Src_Address (Lo order bits) |
+---+----------------+----------------+----------------+--------------+
|10 | DSAP | SSAP | CTRL | OUI |
+---+----------------+----------------+----------------+--------------+
|11 | OUI | PID |
+---+----------------+----------------+----------------+--------------+
|12 | IP Packet Data ... |
+---+----------------+----------------+----------------+--------------+
R_CTL (Routing Control) and TYPE(data structure):
R_CTL（ルーティングコントロール）とタイプ（データ構造）：
Frames for each FC-4 can be easily distinguished from the others at the receiving port using the R_CTL (Routing Control) and TYPE (data structure) fields in the Frame-header.
各FC-4のフレームは、R_CTL（ルーティングコントロール）とタイプ（データ構造）フィールドを使用して、受信ポートの他のフレームと簡単に区別できます。
The R_CTL has two sub-fields: Routing bits and Information category. The Routing bits sub-field has specific values that mean FC-4 data follows and the Information Category tells the receiver the "Type" of data contained in the frame. The R_CTL and TYPE code points are shown in the diagrams.
R_CTLには、ルーティングビットと情報カテゴリの2つのサブフィールドがあります。ルーティングビットサブフィールドには、FC-4データが続くことを意味する特定の値があり、情報カテゴリはフレームに含まれるデータの「タイプ」を受信者に伝えます。R_CTLとタイプのコードポイントは図に示されています。
Other Header fields:
他のヘッダーフィールド：
F_CTL (Frame Control) and SEQ_ID (Sequence Identification), SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), RX_ID (Responder exchange Identifier), and Parameter fields are used to manage the contents of a frame, and mark information exchange boundaries for the destination port.
F_CTL（フレームコントロール）およびSEQ_ID（シーケンス識別）、SEQ_CNT（シーケンスカウント）、OX_ID（オリジネーター交換識別子）、RX_ID（レスポンダー交換識別子）、およびパラメーターフィールドは、フレームの内容を管理し、情報交換境界をマークするために使用されます。宛先ポート用。
F_CTL(Frame Control):
f_ctl（フレームコントロール）：
The FC_CTL field is a 3-byte field that contains information relating to the frame content. Most of the other Frame-header fields are used for frame identification. Among other things, bits in this field indicate the First Sequence, Last Sequence, or End Sequence. Sequence Initiative bit is used to pass control of the next Sequence in the Exchange to the recipient.
FC_CTLフィールドは、フレームコンテンツに関連する情報を含む3バイトフィールドです。他のフレームヘッダーフィールドのほとんどは、フレーム識別に使用されます。とりわけ、このフィールドのビットは、最初のシーケンス、最後のシーケンス、または終了シーケンスを示しています。シーケンスイニシアチブビットは、レシピエントと交換の次のシーケンスの制御を渡すために使用されます。
SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count):
SEQ_ID（シーケンス識別子）およびSEQ_CNT（シーケンスカウント）：
This is used to uniquely identify sequences within an Exchange. The <S_ID, D_ID, SEQ_ID> uniquely identifies any active Sequence. SEQ_CNT is used to uniquely identify frames within a Sequence to assure sequentiality of frame reception, and to allow unique correlation of link control frames with their related data frames.
これは、交換内のシーケンスを一意に識別するために使用されます。<s_id、d_id、seq_id>は、アクティブなシーケンスをユニークに識別します。SEQ_CNTは、シーケンス内のフレームを一意に識別して、フレーム受信の順次性を保証し、関連データフレームとリンク制御フレームの一意の相関を可能にするために使用されます。
Originator Exchange Identifier (OX_ID) and Responder Exchange Identifier (RX_ID):
オリジネーター交換識別子（OX_ID）およびレスポンダー交換識別子（RX_ID）：
The OX_ID value provides association of frames with specific Exchanges originating at a particular N_Port. The RX_ID field provides the same function that the OX_ID provides for the Exchange Originator. The OX_ID is meaningful on the Exchange Originator, and the RX_ID is meaningful on the Responder.
OX_ID値は、フレームと特定のN_PORTで発生する特定の交換との関連を提供します。 RX_IDフィールドは、OX_IDがExchange Originatorに提供するのと同じ機能を提供します。 OX_IDはExchange Originatorで意味があり、RX_IDはレスポンダーで意味があります。
DF_CTL (Data Field Control):
DF_CTL（データフィールドコントロール）：
The DF_CTL field specifies the presence or absence of optional headers between the Frame-header and Frame Payload
DF_CTLフィールドは、フレームヘッダーとフレームペイロードの間にオプションのヘッダーの有無を指定します
PARAMETER:
パラメーター：
The Parameter field has two meanings, depending on Frame type. For Link Control Frames, the Parameter field indicates the specific type of Link Control frame. For Data frames, this field contains the Relative Offset value. This specifies an offset from an Upper Layer Protocol buffer from a base address.
パラメーターフィールドには、フレームタイプに応じて2つの意味があります。リンク制御フレームの場合、パラメーターフィールドは、特定のタイプのリンク制御フレームを示します。データフレームの場合、このフィールドには相対的なオフセット値が含まれています。これは、ベースアドレスから上層プロトコルバッファーからのオフセットを指定します。
The Code Points for FC Frames with IP and ARP Packets are very similar with the exception of PID value in Word 11 which is set to 0x08-00 for IP and 0x08-06 for ARP. Also, the Network_Header appears only in the first logical frame of a FC Sequence carrying IP. In the case, where FC frames carry ARP packets it is always present because these are single frame Sequences.
IPおよびARPパケットを使用したFCフレームのコードポイントは、IPで0x08-00、ARPで0x08-06に設定されているWord 11のPID値を除き、非常に類似しています。また、Network_Headerは、IPを運ぶFCシーケンスの最初の論理フレームにのみ表示されます。FCフレームがARPパケットを運ぶ場合、これらは単一のフレームシーケンスであるため、常に存在します。
Code Points for FC Frame with IP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-00 |
+---+----------------+----------------+----------------+------------+
|12 | IP Packet Data |
+---+----------------+----------------+----------------+------------+
|13 | ... |
+---+----------------+----------------+----------------+------------+
Code Points for FC Frame with ARP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-06 |
+---+----------------+----------------+----------------+------------+
|12 | ARP Packet Data |
+---+----------------+----------------+----------------+------------+
|13| ... |
+---+----------------+----------------+----------------+------------+
The Code Points for a FARP-REQ for a specific Match Address Code Point MATCH_WW_PN_NN ( b'011') is shown below. In particular, note the IP addresses field of the Requester set to a valid address and that of the responder set to '0'. Note also the setting of the D_ID address and the Port_ID of the Responder.
特定のマッチアドレスアドレスコードポイントmatch_ww_pn_nn（b'011 '）のFARP-REQのコードポイントを以下に示します。特に、requesterのIPアドレスのフィールドには、有効なアドレスに設定されたアプローチと、「0」に設定された応答者のアドレスのフィールドに注意してください。また、D_IDアドレスの設定とResponderのPORT_IDにも注意してください。
The corresponding code point for a FARP-REPLY is also shown below. In particular, note the setting of the Port_ID of Responder and the IP address setting of the Responder.
FARP-Replyの対応するコードポイントも以下に示されています。特に、レスポンダーのport_idの設定とレスポンダーのIPアドレス設定に注意してください。
Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID = |
| | | 0xFF 0xFF 0xFF |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x54 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = S_ID |Match Addr. |
| | |Code Points |
| | | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = |Responder |
| | 0x00 0x00 0x00 |Flags |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester if Available |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
| | 0x00-00-00-00 |
|24 | set to a valid IPv4 Address of Responder if available |
+--------------------+----------------+---------+-------------------+
Code Points for FC Frame with FARP-REPLY Command
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x55 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = D_ID | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = S_ID |Resp. Flag |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|24 | set to a valid IPv4 Address by Responder |
+--------------------+----------------+---------+-------------------+
APPENDIX F: Fibre Channel Protocol Considerations
付録F：ファイバーチャネルプロトコルの考慮事項
Problem: Sequence ID reuse in Class 3 can conceivably result in missing frame aliasing, which could result in delivery of corrupted (incorrectly-assembled) data, with no corresponding detection at the FC level.
問題：クラス3でのシーケンスIDの再利用により、フレームエイリアシングが欠落している可能性があり、FCレベルでの対応する検出がないため、破損した（誤って組み立てられた）データの配信が発生する可能性があります。
Prevention: This specification requires one of the following methods if Class 3 is used.
予防：この仕様には、クラス3を使用する場合、次の方法のいずれかが必要です。
- Continuously increasing Sequence Count (new Login Bit) - both sides must set When an N_Port sets the PLOGI login bit for continuously increasing SEQ_CNT, it is guaranteeing that it will transmit all frames within an Exchange using a continuously increasing SEQ_CNT (see description in Section B.1 below). - After using all SEQ_IDs (0-255) once, must start a new Exchange. It is recommended that a minimum of 4 Exchanges be used before an OX_ID can be reused. - Note: If an implementation is not checking the OX_ID when reassembling Sequences, the problem can still occur. Cycling through some number of SEQ_IDs, then jumping to a new Exchange does not solve the problem. SEQ_IDs must still be unique between two N_Ports, even across Exchanges. - Use only single-frame Sequences.
- 継続的に増加したシーケンスカウント（新しいログインビット） - n_portが継続的にSEQ_CNTを増加させるためにPlogiログインビットを設定するときに両側を設定する必要があります。これは、連続的に増加するSEQ_CNTを使用して交換内のすべてのフレームを送信することを保証しています（セクションBの説明を参照してください.1以下）。 - すべてのSEQ_IDS（0-255）を1回使用した後、新しい交換を開始する必要があります。OX_IDを再利用する前に、最低4つの交換を使用することをお勧めします。 - 注：シーケンスを再組み立てするときに実装がOX_IDをチェックしていない場合でも、問題は発生する可能性があります。いくつかのSEQ_IDをサイクリングしてから、新しい交換にジャンプしても問題は解決しません。seq_idsは、取引所全体でさえ、2つのN_portsの間でまだ一意でなければなりません。 - 単一フレームシーケンスのみを使用します。
This method allows the recipient to check incoming frames, knowing exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not repeat for 65,536 frames, the aliasing problem is significantly reduced.
この方法により、受信者は着信フレームをチェックして、次に予想されるSEQ_CNT値を正確に知ることができます。SEQ_CNTは65,536フレームで繰り返されないため、エイリアシングの問題は大幅に減少します。
A Login bit (PLOGI) is used to indicate that a device always uses a continuously increasing SEQ_CNT, even across transfers of Sequence Initiative. This bit is necessary for interoperability with some devices, and it provides other benefits as well.
ログインビット（PLOGI）は、シーケンスイニシアチブの転送全体で、デバイスが常に継続的に増加するSEQ_CNTを使用することを示すために使用されます。このビットは、一部のデバイスとの相互運用性に必要であり、他の利点も提供します。
In the FC-PH-3 [11], the following is supported:
FC-PH-3 [11]では、以下がサポートされています。
Word 1, bit 17 - SEQ_CNT (S) 0 = Normal FC-PH rules apply 1 = Continuously increasing SEQ_CNT
ワード1、ビット17 -seq_cnt（s）0 =通常のfc -phルール適用1 =継続的にseq_cntの増加
Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will transmit all frames within an Exchange using a continuously increasing SEQ_CNT. Each Exchange SHALL start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that SHALL increment the previous SEQ_CNT by one, even across transfers of Sequence Initiative. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
ワード1、ビット17 = 1を設定するN_portは、連続的に増加するSEQ_CNTを使用して、交換内のすべてのフレームを送信することを保証しています。各交換は、最初のフレームでSEQ_CNT = 0から開始し、その後送信されたすべてのフレームは、シーケンスイニシアチブの転送全体にわたって、以前のSEQ_CNTを1つずつ増加させます。交換中の他のN_PORTから受け取ったフレームは、送信されたSEQ_CNTに影響を与えません。
Appendix G: Acronyms and Glossary of FC Terms
付録G：FC用語の頭字語と用語集
It is assumed that the reader is familiar with the terms and acronyms used in the FC protocol specification [2]. The following is provided for easy reference.
読者は、FCプロトコル仕様で使用される用語と頭字語に精通していると想定されています[2]。簡単に参照できるように、以下が提供されています。
First Frame: The frame that contains the SOFi field. This means a logical first and may not necessarily be the first frame temporally received in a sequence.
最初のフレーム：SOFIフィールドを含むフレーム。これは、最初の論理を意味し、必ずしも順番に一時的に受信された最初のフレームであるとは限りません。
Code Point: The coded bit pattern associated with control fields in frames or packets.
コードポイント：フレームまたはパケットの制御フィールドに関連付けられたコード化されたビットパターン。
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for aborting an exchange based on the ABTS recipient setting the Last_Sequence bit in the BA_ACC ELS to the ABTS
ABTS_LS：ABORTシーケンスプロトコル - 最後のシーケンス。ABTS受信者に基づいてExchangeを中止するためのプロトコルは
ADISC: Discover Address. An ELS for discovering the Hard Addresses (the 24 bit NL_Port Identifier) of N_Ports
Adisc：アドレスを発見します。n_portsのハードアドレス（24ビットNL_port識別子）を発見するためのELS
D_ID: Destination ID
D_ID：宛先ID
ES: End sequence. This FCTL bit in the FC header indicates this frame is the last frame of the sequence.
ES：終了シーケンス。FCヘッダーのこのFCTLビットは、このフレームがシーケンスの最後のフレームであることを示しています。
FAN: Fabric Address Notification. An ELS sent by the fabric to all known previously Logged in ports following an initialization event.
ファン：ファブリックアドレス通知。初期化イベントに続いて、以前にログインしたすべての既知のポートにファブリックから送信されたELS。
FLOGI: Fabric Login.
Flogi：ファブリックログイン。
LIP: Loop Initialization. A primitive Sequence used by a port to detect if it is part of a loop or to recover from certain loop errors.
リップ：ループ初期化。ポートがループの一部であるかどうかを検出するか、特定のループエラーから回復するためにポートが使用するプリミティブシーケンス。
Link: Two unidirectional paths flowing in opposite directions and connecting two Ports within adjacent Nodes.
リンク：反対方向に流れ、隣接するノード内の2つのポートを接続する2つの単方向パス。
LOGO: Logout.
ロゴ：ログアウト。
LR: Link reset. A primitive sequence transmitted by a port to initiate the link reset protocol or to recover from a link timeout.
LR：リンクリセット。リンクリセットプロトコルを開始するか、リンクタイムアウトから回復するためにポートによって送信されたプリミティブシーケンス。
LS: Last Sequence of Exchange. This FCTL bit in the FC header indicates the Sequence is the Last Sequence of the Exchange.
LS：交換の最後のシーケンス。FCヘッダーのこのFCTLビットは、シーケンスが交換の最後のシーケンスであることを示します。
Network Address Authority: A 4-bit field specified in Network_Headers that distinguishes between various name registration authorities that may be used to identify the WW_PN and the WW_NN. NAA=b'0001' indicates IEEE-48-bit MAC addresses
ネットワークアドレスの権限：ww_pnとww_nnを識別するために使用できるさまざまな名前登録当局を区別するネットワーク_headersで指定された4ビットフィールド。NAA = B'0001 'はIEEE-48ビットMACアドレスを示します
Node: A collection of one or more Ports identified by a unique World Wide Node Name (WW_NN).
ノード：一意のワールドワイドノード名（ww_nn）によって識別される1つ以上のポートのコレクション。
NOS: Not Operational. A primitive Sequence transmitted to indicate that the port transmitting this Sequence has detected a link failure or is offline, waiting for OLS to be received.
NOS：操作性はありません。このシーケンスを送信するポートがリンク障害を検出したか、オフラインであることを示すために送信されたプリミティブシーケンス。OLSが受信されるのを待っています。
OLS: Off line. A primitive Sequence transmitted to indicate that the port transmitting this Sequence is either initiating the link initialization protocol, receiving and recognizing NOS, or entering the offline state.
OLS：オフライン。このシーケンスを送信するポートがリンク初期化プロトコルを開始し、NOSを受信および認識するか、オフライン状態に入ることを示すために送信されたプリミティブシーケンス。
PDISC: Discover Port. An ELS for exchanging Service Parameters without affecting Login state.
PDISC：ポートを発見します。ログイン状態に影響を与えることなく、サービスパラメーターを交換するためのELS。
Primitive Sequence: A primitive Sequence is an Ordered Set that is transmitted repeatedly and continuously.
プリミティブシーケンス：プリミティブシーケンスは、繰り返しかつ連続的に送信される順序付けセットです。
Private Loop Device: A device that does not attempt Fabric Login (FLOGI) and usually adheres to PLDA. The Area and Domain components of the NL_Port ID must be 0x0000. These devices cannot communicate with any port not in the local loop.
プライベートループデバイス：ファブリックログイン（FLOGI）を試みず、通常はPLDAに準拠するデバイス。NL_PORT IDの領域とドメインコンポーネントは0x0000でなければなりません。これらのデバイスは、ローカルループではなくポートと通信できません。
Public Loop Device: A device whose Area and Domain components of the NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the device must attempt to open AL_PA 0x00 and attempt FLOGI. These devices communicate with devices on the local loop as well as devices on the other side of a Fabric.
パブリックループデバイス：NL_PORT IDの領域とドメインコンポーネントが0x0000ではないデバイス。さらに、FLAに準拠するには、デバイスはAL_PA 0x00を開き、Flogiを試みようと試みなければなりません。これらのデバイスは、ローカルループ上のデバイスと、ファブリックの反対側のデバイスと通信します。
Port: The transmitter, receiver and associated logic at either end of a link within a Node. There may be multiple Ports per Node. Each Port is identified by a unique Port_ID, which is volatile, and a unique World Wide Port Name (WW_PN), which is unchangeable. In this document, the term "port" may be used interchangeably with NL_Port or N_Port.
ポート：ノード内のリンクの両端にある送信機、受信機、および関連するロジック。ノードごとに複数のポートがある場合があります。各ポートは、不安定な一意のPORT_IDと、不変の一意のWorld Wide Port Name（ww_pn）によって識別されます。このドキュメントでは、「ポート」という用語は、NL_PORTまたはN_PORTと交換可能に使用できます。
Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. In a Fibre Channel frame header, the Port_ID is referred to as S_ID (Source ID) to identify the port originating a frame, and D_ID to identify the destination port. The Port_ID of a given port is volatile (changeable).
PORT_ID：ファイバーチャネルポートは、一意の24ビットPORT_IDSによって対処されています。ファイバーチャネルフレームヘッダーでは、PORT_IDはS_ID（ソースID）と呼ばれ、フレームを作成するポートを識別し、D_IDは宛先ポートを識別します。特定のポートのport_idは揮発性（変更可能）です。
PLOGI: Port Login.
Plogi：ポートログイン。
SI: Sequence Initiative
SI：シーケンスイニシアチブ
World Wide Port_Name (WW_PN): Fibre Channel requires each Port to have an unchangeable WW_PN. Fibre Channel specifies a Network Address Authority (NAA) to distinguish between the various name registration authorities that may be used to identify the WW_PN. A 4-bit NAA identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address together make this a 64-bit field.
World Wide Port_name（ww_pn）：ファイバーチャネルでは、各ポートに変更不可能なww_pnが必要です。ファイバーチャネルは、ww_pnを識別するために使用できるさまざまな名前登録当局を区別するために、ネットワークアドレス機関（NAA）を指定します。4ビットNAA識別子、12ビットフィールドが0x0に設定され、IEEE 48ビットMACアドレスが一緒になって、これを64ビットフィールドにします。
World Wide Node_Name (WW_NN): Fibre Channel identifies each Node with a unchangeable WW_NN. In a single port Node, the WW_NN and the WW_PN may be identical.
World Wide node_name（ww_nn）：ファイバーチャネルは、変更不可能なww_nnで各ノードを識別します。単一のポートノードでは、ww_nnとww_pnが同一である可能性があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。