[要約] RFC 3831は、IPv6パケットをFibre Channel経由で転送するための仕様を提供しています。このRFCの目的は、IPv6ネットワークとFibre Channelネットワークの統合を可能にし、IPv6トラフィックをFibre Channelベースのネットワークで効率的に転送することです。
Network Working Group C. DeSanti
Request for Comments: 3831 Cisco Systems
Category: Standards Track July 2004
Transmission of IPv6 Packets over Fibre Channel
ファイバーチャネル上のIPv6パケットの送信
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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.
このドキュメントは、ファイバーチャネル上のIPv6パケットをカプセル化する方法と、Fiberチャネルネットワーク上のIPv6リンクローカルアドレスとステートレレスオートコンフィグ付きアドレスを形成する方法を指定します。
Table Of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Fibre Channel . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifiers and Login. . . . . . . . . . . . . . . . . . 3
2.3. FC Levels and Frame Format . . . . . . . . . . . . . . . 4
2.4. Sequences and Exchanges . . . . . . . . . . . . . . . . 5
3. IPv6 Capable Nx_Ports. . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FC Sequence Format . . . . . . . . . . . . . . . . . . . 6
4.2. FC Classes of Service. . . . . . . . . . . . . . . . . . 8
4.3. FC Header Code Points. . . . . . . . . . . . . . . . . . 8
4.4. FC Network_Header. . . . . . . . . . . . . . . . . . . . 9
4.5. LLC/SNAP Header. . . . . . . . . . . . . . . . . . . . . 9
4.6. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 9
5. Maximum Transfer Unit. . . . . . . . . . . . . . . . . . . . . 10
6. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 10
6.1. IPv6 Interface Identifier and Address Prefix . . . . . . 10
6.2. Generating an Interface ID from a Format 1
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Generating an Interface ID from a Format 2
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Generating an Interface ID from a Format 5
N_Port_Name. . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Generating an Interface ID from an EUI-64
mapped N_Port_Name . . . . . . . . . . . . . . . . . . . 14
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . . 15
8. Address Mapping for Unicast. . . . . . . . . . . . . . . . . . 15
9. Address Mapping for Multicast. . . . . . . . . . . . . . . . . 16
10. Sequence Management. . . . . . . . . . . . . . . . . . . . . . 17
11. Exchange Management. . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References. . . . . . . . . . . . . . . . . . 18
14.2. Informative References. . . . . . . . . . . . . . . . . 19
A. Transmission of a Broadcast FC Sequence over FC Topologies . . 20
B. Validation of the <N_Port_Name, N_Port_ID> mapping . . . . . . 21
C. Fibre Channel Bit and Byte Numbering Guidance. . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 24
Fibre Channel (FC) is a high speed serial interface technology that supports several Upper Layer Protocols including Small Computer System Interface (SCSI) and IPv4 as specified in [IPFC].
ファイバーチャネル（FC）は、[IPFC]で指定されているように、小さなコンピューターシステムインターフェイス（SCSI）やIPv4を含むいくつかの上層プロトコルをサポートする高速シリアルインターフェイステクノロジーです。
The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network.
このドキュメントの目的は、ファイバーチャネルを介してIPバージョン6 [IPv6]をカプセル化する方法を指定し、ファイバーチャネルネットワーク上のIPv6リンクローカルアドレス[AARCH]およびステートレレスオートコンチュードアドレスを形成する方法を説明することです。このドキュメントでは、ファイバーチャネルネットワークでメッセージが送信されたときに、Neighbor Discovery [disc]で使用されるソース/ターゲットリンクレイヤーアドレスオプションの内容についても説明します。
Warning to readers familiar with Fibre Channel: both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different. See Appendix C for guidance.
ファイバーチャネルに精通している読者への警告：ファイバーチャネルとIETF標準の両方が同じバイト伝送順序を使用します。ただし、ビット番号は異なります。ガイダンスについては、付録Cを参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
Fibre Channel (FC) is a gigabit speed network technology primarily used for Storage Networking. Fibre Channel is standardized in the T11 Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standard Institute (ANSI) accredited standards committee.
Fiber Channel（FC）は、主にストレージネットワーキングに使用されるギガビットスピードネットワークテクノロジーです。Fiber Channelは、American National Standard Institute（ANSI）認定基準委員会であるInternational Information Technology Standards（INCITS）のT11技術委員会に標準化されています。
Fibre Channel devices are called Nodes. Each Node has one or more Ports that connect to Ports of other devices. Fibre Channel may be implemented using any combination of the following three topologies:
ファイバーチャネルデバイスはノードと呼ばれます。各ノードには、他のデバイスのポートに接続する1つ以上のポートがあります。ファイバーチャネルは、次の3つのトポロジの任意の組み合わせを使用して実装できます。
- a point-to-point link between two Ports; - a set of Ports interconnected by a switching network called a Fabric, as defined in [FC-FS]; - a set of Ports interconnected with a loop topology, as defined in [FC-AL-2].
- 2つのポート間のポイントツーポイントリンク。 - [FC-FS]で定義されているように、ファブリックと呼ばれるスイッチングネットワークによって相互接続されたポートのセット。 - [FC-AL-2]で定義されているように、ループトポロジと相互接続されたポートのセット。
A Node Port is more precisely called an N_Port. A Node Port that is capable of operating in a loop topology using the loop specific protocols is designated as an NL_Port. The term Nx_Port is used to generically indicate these two kinds of Node Port.
ノードポートは、より正確にN_PORTと呼ばれます。ループ固有のプロトコルを使用してループトポロジを操作できるノードポートは、NL_PORTとして指定されています。NX_PORTという用語は、これら2種類のノードポートを一般的に示すために使用されます。
A Fabric Port is more precisely called an F_Port. A Fabric Port that is capable of operating in a loop topology using the loop specific protocols is designated as an FL_Port. The term Fx_Port is used to generically indicate these two kinds of Fabric Port.
ファブリックポートは、より正確にF_Portと呼ばれます。ループ固有のプロトコルを使用してループトポロジで動作できるファブリックポートは、FL_PORTとして指定されています。FX_PORTという用語は、これら2種類のファブリックポートを一般的に示すために使用されます。
From an IPv6 point of view, a Fibre Channel network, built with any combination of the FC topologies described above, is an IPv6 Link [IPv6]. IPv6-capable Nx_Ports are what [IPv6] calls Interfaces.
IPv6の観点からは、上記のFCトポロジーの任意の組み合わせで構築されたファイバーチャネルネットワークは、IPv6リンク[IPv6]です。IPv6対応NX_PORTSは、[IPv6]がインターフェイスと呼ぶものです。
Fibre Channel entities are identified by permanent 64 bit long Name_Identifiers. [FC-FS] defines several formats of Name_Identifiers. The value of the first four bits defines the format of a Name_Identifier. These names are referred to in a more precise manner as follows:
ファイバーチャネルエンティティは、永続的な64ビットの長いname_identifiersによって識別されます。[FC-FS]は、name_identifiersのいくつかの形式を定義します。最初の4ビットの値は、name_identifierの形式を定義します。これらの名前は、より正確な方法で次のように言及されています。
- an Nx_Port's Name_Identifier is called N_Port_Name; - an Fx_Port's Name_Identifier is called F_Port_Name; - a Node's Name_Identifier is called Node_Name; - a Fabric's Name_Identifier is called Fabric_Name.
- nx_portのname_identifierはn_port_nameと呼ばれます。-fx_portのname_identifierはf_port_nameと呼ばれます。-Nodeのname_identifierはnode_nameと呼ばれます。 - ファブリックのname_identifierはfabric_nameと呼ばれます。
An Nx_Port connected to a Fibre Channel network is associated with two identifiers, its permanent N_Port_Name and a volatile 24 bit address called N_Port_ID. The N_Port_Name is used to identify the Nx_Port, while the N_Port_ID is used for communications among Nx_Ports.
ファイバーチャネルネットワークに接続されたNX_PORTは、その永続的なN_PORT_NAMEとN_PORT_IDと呼ばれる揮発性24ビットアドレスの2つの識別子に関連付けられています。N_PORT_NAMEはNX_PORTを識別するために使用され、N_PORT_IDはNX_PORTS間の通信に使用されます。
Each Nx_Port acquires an N_Port_ID from the Fabric by performing a process called Fabric Login or FLOGI. The FLOGI process is used also to negotiate several communications parameters between the Nx_Port and the Fabric, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the Nx_Port and the Fabric.
各NX_PORTは、ファブリックログインまたはFLOGIと呼ばれるプロセスを実行することにより、ファブリックからN_PORT_IDを取得します。FLOGIプロセスは、NX_PORTとファブリックサイズなど、NX_PORTとファブリックの間にいくつかの通信パラメーターを交渉するために使用されます。
Before effective communication may take place between two Nx_Ports, they must complete a process called Port Login or PLOGI. The PLOGI process provides each Nx_Port with the other Nx_Port's N_Port_Name, and negotiates several communication parameters, such as the receive data field size, which determines the maximum size of the Fibre Channel frames that may be transferred between the two Nx_Ports.
2つのNX_PORTS間で効果的な通信が行われる前に、ポートログインまたはPLOGIと呼ばれるプロセスを完了する必要があります。PLOGIプロセスは、各NX_PORTに他のNX_PORTのN_PORT_NAMEを提供し、受信データフィールドサイズなどのいくつかの通信パラメーターを交渉し、2つのNX_PORTS間で転送されるファイバーチャネルフレームの最大サイズを決定します。
Both Fabric Login and Port Login may be explicit, i.e., performed using specific FC control messages (called Extended Link Services or ELS), or implicit, in which the parameters are specified by configuration or other methods.
ファブリックログインとポートログインの両方が明示的である場合があります。つまり、特定のFC制御メッセージ（拡張リンクサービスまたはELと呼ばれる）を使用して実行されるか、パラメーターが構成またはその他のメソッドで指定されている暗黙的です。
[FC-FS] describes the Fibre Channel protocol using 5 different levels. The FC-2 and FC-4 levels are relevant for this specification. The FC-2 level defines the FC frame format, the transport services, and control functions necessary for information transfer. The FC-4 level supports Upper Level Protocols, such as IPv4, IPv6 or SCSI. The Fibre Channel frame format is depicted in figure 1.
[FC-FS]は、5つの異なるレベルを使用してファイバーチャネルプロトコルを説明しています。FC-2およびFC-4レベルは、この仕様に関連しています。FC-2レベルは、情報転送に必要なFCフレーム形式、輸送サービス、および制御機能を定義します。FC-4レベルは、IPv4、IPv6、SCSIなどの上位レベルのプロトコルをサポートしています。ファイバーチャネルフレーム形式を図1に示します。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Fig. 1: Fibre Channel Frame Format
図1：ファイバーチャネルフレーム形式
The Start of Frame (SOF) and End of Frame (EOF) are special FC transmission words that act as frame delimiters. The CRC is 4 octets long and uses the same 32-bit polynomial used in FDDI.
フレームの開始（SOF）とフレームの終了（EOF）は、フレームデリミターとして機能する特別なFC伝送ワードです。CRCの長さは4オクターで、FDDIで使用される同じ32ビット多項式を使用しています。
The FC Header is 24 octets long and contains several fields associated with the identification and control of the Data Field.
FCヘッダーの長さは24オクターで、データフィールドの識別と制御に関連するいくつかのフィールドが含まれています。
The Data Field is of variable size, ranging from 0 to 2112 octets, and includes the user data in the Frame Payload field, and Optional Headers. The currently defined Optional Headers are:
データフィールドは、0〜2112オクテットの範囲の可変サイズで、フレームペイロードフィールドのユーザーデータとオプションのヘッダーが含まれています。現在定義されているオプションのヘッダーは次のとおりです。
- ESP_Header; - Network_Header; - Association_Header; - Device_Header.
- esp_header;-network_header;-Association_header;-device_header。
The value of the SOF field determines the FC Class of service associated with the frame. Five Classes of service are specified in [FC-FS]. They are distinguished primarily by the method of flow control between the communicating Nx_Ports and by the level of data integrity provided. A given Fabric or Nx_Port may support one or more of the following Classes of service:
SOFフィールドの値は、フレームに関連付けられたFCクラスのサービスクラスを決定します。5つのクラスのサービスが[FC-FS]で指定されています。これらは、主に通信NX_PORTS間のフロー制御の方法と、提供されるデータの整合性のレベルによって区別されます。特定のファブリックまたはNX_PORTは、次のクラスの1つ以上のサービスをサポートできます。
- Class 1: Dedicated physical connection with delivery confirmation; - Class 2: Frame multiplexed service with delivery confirmation; - Class 3: Datagram service; - Class 4: Fractional bandwidth; - Class 6: Reliable multicast via dedicated connections.
- クラス1：配信確認との専用の物理的接続。 - クラス2：配信確認を備えたフレーム多重化サービス。 - クラス3：データグラムサービス。 - クラス4：分数帯域幅。 - クラス6：専用の接続を介した信頼性の高いマルチキャスト。
An application level payload such as IPv6 is called Information Unit at the FC-4 level of Fibre Channel. Each FC-4 Information Unit is mapped to an FC Sequence by the FC-2 level. An FC Sequence consists of one or more FC frames related by the value of the Sequence_ID (SEQ_ID) field of the FC Header.
IPv6などのアプリケーションレベルのペイロードは、FC-4レベルのファイバーチャネルで情報ユニットと呼ばれます。各FC-4情報ユニットは、FC-2レベルによってFCシーケンスにマッピングされます。FCシーケンスは、FCヘッダーのSequence_ID（SEQ_ID）フィールドの値に関連する1つ以上のFCフレームで構成されています。
The maximum data that may be carried by an FC frame is 2112 octets. The maximum usable frame size depends on the Fabric and Nx_Port implementations and is negotiated during the Login process. Whenever an Information Unit to be transmitted exceeds this value, the FC-2 level segments it into multiple FC frames, sent as a single Sequence. The receiving Nx_Port reassembles the Sequence of frames and delivers a reassembled Information Unit to the FC-4 level. The Sequence Count (SEQ_CNT) field of the FC Header may be used to ensure frame ordering.
FCフレームで運ばれる可能性のある最大データは2112オクテットです。最大使用可能なフレームサイズは、ファブリックとNX_PORTの実装に依存し、ログインプロセス中にネゴシエートされます。送信される情報ユニットがこの値を超えるたびに、FC-2レベルはそれを複数のFCフレームにセグメントし、単一のシーケンスとして送信します。受信NX_PORTは、フレームのシーケンスを再組み立てし、FC-4レベルに再構築された情報ユニットを提供します。FCヘッダーのシーケンスカウント（SEQ_CNT）フィールドを使用して、フレームの順序付けを確実にすることができます。
Multiple Sequences may be related together as belonging to the same FC Exchange. The Exchange is a mechanism used by two Nx_Ports to identify and manage an operation between them. The Exchange is opened when the operation is started between the two Nx_Ports, and closed when the operation ends. FC frames belonging to the same Exchange are related by the value of the Exchange_ID fields in the FC Header. An Originator Exchange_ID (OX_ID) and a Responder Exchange_ID (RX_ID) uniquely identify the Exchange.
複数のシーケンスは、同じFC交換に属するものとして一緒に関連している可能性があります。交換は、2つのNX_PORTSが使用するメカニズムであり、それらの間の操作を識別および管理します。2つのNX_PORTSの間で操作が開始されると交換が開かれ、操作が終了すると閉じられます。同じ交換に属するFCフレームは、FCヘッダーのExchange_IDフィールドの値に関連しています。Originator Exchange_id（ox_id）とレスポンダーExchange_id（rx_id）がExchangeを一意に識別します。
This specification requires an IPv6 capable Nx_Port to have the following properties:
この仕様では、次のプロパティを持つためにIPv6対応NX_PORTが必要です。
- The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF (see section 6.1). IPv6 support for other Name_Identifier formats is outside the scope of this specification; - It MUST support Class 3; - It MUST support continuously increasing SEQ_CNT [FC-FS]; - It MUST be able to transmit and receive an FC-4 Information Unit at least 1304 octets long; - It SHOULD support a receive data field size for Device_Data FC frames of at least 1024 octets.
- N_PORT_NAMEの形式は、0x1、0x2、0x5、0xc、0xd、0xe、0xfのいずれかでなければなりません（セクション6.1を参照）。他のname_identifier形式のIPv6サポートは、この仕様の範囲外です。 - クラス3をサポートする必要があります。-SEQ_CNT [FC-FS]を継続的に増加させることをサポートする必要があります。 - 少なくとも1304オクテットのFC-4情報ユニットを送信および受信できる必要があります。-1024オクテットのDevice_Data FCフレームのデータフィールドサイズの受信をサポートする必要があります。
An IPv6 packet is mapped to an Information Unit at the FC-4 level of Fibre Channel, which in turn is mapped to an FC Sequence by the FC-2 level. An FC Information Unit containing an IPv6 packet MUST carry the FC Network_Header [FC-FS] and the LLC/SNAP header [IEEE-LLC], resulting in the FC Information Unit format depicted in figure 2.
IPv6パケットは、FC-4レベルのファイバーチャネルの情報ユニットにマッピングされ、FC-2レベルによってFCシーケンスにマッピングされます。IPv6パケットを含むFC情報ユニットは、FC Network_Header [FC-FS]とLLC/SNAPヘッダー[IEEE-LLC]を搭載する必要があります。
+---------------+---------------+---------------+---------------+
| |
+- -+
| Network_Header |
+- (16 octets) -+
| |
+- -+
| |
+---------------+---------------+---------------+---------------+
| LLC/SNAP header |
+- (8 octets) -+
| |
+---------------+---------------+---------------+---------------+
| |
+- -+
/ IPv6 Packet /
/ /
+- -+
| |
+---------------+---------------+---------------+---------------+
Fig. 2: FC Information Unit Mapping an IPv6 Packet
図2：IPv6パケットをマッピングするFC情報ユニット
The FC ESP_Header [FC-FS] MAY be used to secure the FC frames composing the FC Sequence. [AH] or [ESP] may be used to provide security at the IPv6 layer. Other types of FC Optional Header MUST NOT be used in an IPv6 FC Sequence.
FC ESP_Header [FC-FS]を使用して、FCシーケンスを構成するFCフレームを保護できます。[AH]または[ESP]を使用して、IPv6レイヤーでセキュリティを提供できます。他のタイプのFCオプションヘッダーは、IPv6 FCシーケンスで使用しないでください。
Typically, a Sequence consists of more than one frame. Only the first frame of the Sequence MUST include the FC Network_Header and the LLC/SNAP header. The other frames MUST NOT include them, as depicted in figure 3.
通常、シーケンスは複数のフレームで構成されます。シーケンスの最初のフレームのみにのみ、FC Network_headerとLLC/SNAPヘッダーを含める必要があります。他のフレームには、図3に示すように、それらを含めてはなりません。
First Frame of an IPv6 FC Sequence
+-----------+-------------------+-----------------+-------//--------+
| FC Header | FC Network_Header | LLC/SNAP header | First chunk of |
| | | | the IPv6 Packet |
+-----------+-------------------+-----------------+-------//--------+
Subsequent Frames of an IPv6 FC Sequence
+-----------+-----------------//------------------+
| FC Header | Additional chunk of the IPv6 Packet |
+-----------+----------------//-------------------+
Fig. 3: Optional Headers in an IPv6 FC Sequence
図3：IPv6 FCシーケンスのオプションヘッダー
This specification uses FC Class 3. IPv6 packets carrying Neighbor Discovery [DISC] messages MUST be encapsulated in Class 3 FC frames. Other IPv6 packets SHOULD use Class 3 as well. The use of other Classes of service is outside the scope of this specification.
この仕様では、FCクラス3を使用しています。近隣発見[disc]メッセージを運ぶIPv6パケットは、クラス3 FCフレームにカプセル化する必要があります。他のIPv6パケットもクラス3を使用する必要があります。他のクラスのサービスの使用は、この仕様の範囲外です。
The fields of the Fibre Channel Header are depicted in figure 4. The D_ID and S_ID fields contain respectively the destination N_Port_ID and the source N_Port_ID. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
ファイバーチャネルヘッダーのフィールドを図4に示します。D_IDおよびS_IDフィールドには、それぞれ宛先N_PORT_IDとソースN_PORT_IDが含まれています。ファイバーチャネルを介してIPv6をカプセル化するには、次のコードポイントを使用する必要があります。
- R_CTL: 0x04 (Device_Data frame with Unsolicited Data Information Category [FC-FS]) - TYPE: 0x05 (IP over Fibre Channel) - CS_CTL/Prio: 0x0 - DF_CTL: 0x20 (Network_Header) for the first FC frame of an IPv6 Sequence, 0x00 for the following FC frames. If the FC ESP_Header is used, then 0x60 for the first FC frame of an IPv6 Sequence, 0x40 for the following FC frames. - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID, Parameter: see section 10, section 11, and [FC-FS] for additional requirements.
- r_ctl：0x04（device_data frame with unsatleatited data information category [fc -fs]） - タイプ：0x05（ファイバーチャネル上） - cs_ctl/prio：0x0 -df_ctl：0x20（network_header）IPv6シーケンスの最初のFCフレーム、次のFCフレームの0x00。FC ESP_Headerを使用する場合は、IPv6シーケンスの最初のFCフレームで0x60、次のFCフレームで0x40。-f_ctl、seq_id、seq_cnt、ox_id、rx_id、パラメーター：追加要件については、セクション10、セクション11、および[FC-FS]を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R_CTL | D_ID |
+---------------+---------------+---------------+---------------+
| CS_CTL/Prio | S_ID |
+---------------+---------------+---------------+---------------+
| TYPE | F_CTL |
+---------------+---------------+---------------+---------------+
| SEQ_ID | DF_CTL | SEQ_CNT |
+---------------+---------------+---------------+---------------+
| OX_ID | RX_ID |
+---------------+---------------+---------------+---------------+
| Parameter |
+---------------+---------------+---------------+---------------+
Fig. 4: FC Header Format
図4：FCヘッダー形式
The fields of the FC Network_Header are depicted in figure 5. For use with IPv6 the N_Port_Names formats MUST be one of 0x1, 0x2, 0x5, 0xC, 0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is outside the scope of this specification.
FC Network_Headerのフィールドを図5に示します。IPv6で使用するには、N_PORT_NAMESフォーマットは0x1、0x2、0x5、0xc、0xd、0xe、0xfのいずれかでなければなりません。他のname_identifier形式のIPv6サポートは、この仕様の範囲外です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Destination N_Port_Name -+
| |
+---------------------------------------------------------------+
| |
+- Source N_Port_Name -+
| |
+---------------------------------------------------------------+
Fig. 5: FC Network_Header Format
図5：FC Network_header形式
The fields of the LLC/SNAP Header [IEEE-LLC] are depicted in figure 6. To encapsulate IPv6 over Fibre Channel the following code points MUST be used:
LLC/SNAPヘッダー[IEEE-LLC]のフィールドを図6に示します。ファイバーチャネル上でIPv6をカプセル化するには、次のコードポイントを使用する必要があります。
- DSAP: 0xAA - SSAP: 0xAA - CTRL: 0x03 - OUI: 0x00-00-00 - PID: 0x86-DD
- DSAP：0xaa -SSAP：0xaa -ctrl：0x03 -oui：0x00-00-00 -pid：0x86 -dd
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP | CTRL | OUI |
+---------------+---------------+---------------+---------------+
| OUI | PID |
+---------------+---------------+---------------+---------------+
Fig. 6: LLC/SNAP Header Format
図6：LLC/スナップヘッダー形式
IPv6 packets are mapped to the FC-4 level using the big-endian byte ordering that corresponds to the standard network byte order or canonical form.
IPv6パケットは、標準のネットワークバイト順序または標準形式に対応するビッグエンディアンバイト順序を使用して、FC-4レベルにマッピングされます。
The default MTU size for IPv6 [IPv6] packets over Fibre Channel is 65280 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option that specifies a smaller MTU, or by manual configuration of each Nx_Port. However, as required by [IPv6], the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement received on an Nx_Port has an MTU option specifying an MTU larger than 65280, or larger than a manually configured value, that MTU option MAY be logged to system management but MUST be otherwise ignored.
ファイバーチャネル上のIPv6 [IPv6]パケットのデフォルトのMTUサイズは65280オクテットです。このサイズは、小さいMTUを指定するMTUオプションを含むルーター広告[disc]、または各NX_PORTの手動構成によって縮小できます。ただし、[IPv6]で要求されているように、MTUは1280オクテットよりも低くてはなりません。NX_PORTで受信したルーター広告には、65280を超えるMTUを指定するMTUオプションがある場合、または手動で構成された値よりも大きいMTUオプションがある場合、そのMTUオプションはシステム管理にログに記録される可能性がありますが、それ以外の場合は無視する必要があります。
As the default MTU size far exceeds the message sizes typically used in the Internet, an IPv6 over FC implementation SHOULD implement Path MTU Discovery [PMTUD], or at least maintain different MTU values for on-link and off-link destinations.
デフォルトのMTUサイズがインターネットで通常使用されるメッセージサイズをはるかに上回るため、FCの実装を介してIPv6の実装はPATH MTU発見[PMTUD]を実装するか、少なくともオンリンクおよびリンクの宛先の異なるMTU値を維持する必要があります。
For correct operation in a routed environment, it is critically important to configure an appropriate MTU option in Router Advertisements.
ルーティングされた環境での正しい操作のために、ルーター広告で適切なMTUオプションを構成することが非常に重要です。
For correct operation when mixed media (e.g., Ethernet and Fibre Channel) are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with a default MTU larger than the smallest MTU.
混合メディア（イーサネットとファイバーチャネルなど）が一緒に橋渡しされる場合、正しい操作のために、すべてのメディアの最小のMTUは、MTUオプションのルーターによって宣伝される必要があります。ルーターが存在しない場合、このMTUは、最小のMTUよりも大きいデフォルトのMTUを持つメディアに接続されている各ノードで手動で構成する必要があります。
The IPv6 Interface ID [AARCH] for an Nx_Port is based on the EUI-64 address [EUI64] derived from the Nx_Port's N_Port_Name. The IPv6 Interface Identifier is obtained by complementing the Universal/Local bit of the OUI field of the derived EUI-64 address.
NX_PORTのIPv6インターフェイスID [AARCH]は、NX_PORTのN_PORT_NAMEに由来するEUI-64アドレス[EUI64]に基づいています。IPv6インターフェイス識別子は、派生したEUI-64アドレスのOUIフィールドの普遍的/ローカルビットを補完することにより取得されます。
[FC-FS] specifies a method to map format 0x1 (IEEE 48 bit address), or 0x2 (IEEE Extended), or 0x5 (IEEE Registered) FC Name_Identifiers in EUI-64 addresses. This allows the usage of these Name_Identifiers to support IPv6. [FC-FS] also defines EUI-64 mapped FC Name_Identifiers (formats 0xC, 0xD, 0xE, and 0xF), that are derived from an EUI-64 address. It is possible to reverse this address mapping to obtain the original EUI-64 address in order to support IPv6.
[FC-FS] EUI-64アドレスで0x1（IEEE 48ビットアドレス）、または0x5（IEEE登録）FC name_identifiersをマッピングする方法を指定します。これにより、これらのname_identifiersの使用がIPv6をサポートすることができます。[FC-FS]は、EUI-64アドレスから派生したEUI-64マッピングFC name_identifiers（フォーマット0xc、0xd、0xe、および0xf）も定義します。IPv6をサポートするために、このアドレスマッピングを逆転させて元のEUI-64アドレスを取得することができます。
Stateless address autoconfiguration MUST be performed as specified in [ACONF]. An IPv6 Address Prefix used for stateless address autoconfiguration of an Nx_Port MUST have a length of 64 bits.
ステートレスアドレスAutoconfigurationは、[ACONF]で指定されているように実行する必要があります。NX_PORTのステートレスアドレスに使用されるIPv6アドレスプレフィックスは、64ビットの長さを持っている必要があります。
The Name_Identifier format 0x1 is depicted in figure 7.
name_identifier形式0x1を図7に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0x000 | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 7: Format 0x1 Name_Identifier
図7：フォーマット0x1 name_identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 8 [FC-FS].
このname_identifierから派生したEUI-64アドレスには、図8 [FC-FS]に示されている形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 8: EUI-64 Address from a Format 0x1 Name_Identifier
図8：FORMAT 0x1 name_identifierのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 9.
IPv6インターフェイス識別子は、OUIフィールドのU/Lビットを補完することにより、このEUI-64アドレスから取得されます。したがって、IPv6インターフェイスIDのOUIは、FC name_identifierとまったく同じです。結果のIPv6インターフェイス識別子には、ローカルスコープ[AARCH]と図9に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 0 1| VSID |
+---------------+---------------+-------+-------+-------+-------+
| VSID | 0x000 |
+---------------+---------------+-------+-------+---------------+
Fig. 9: IPv6 Interface ID from a Format 0x1 Name_Identifier
図9：フォーマット0x1 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x10-00-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:461A:BCDE:F000.
例として、FC name_identifier 0x10-00-34-63-46-AB-CD-EFは、IPv6インターフェイス識別子3463：461a：BCDE：F000を生成します。
The Name_Identifier format 0x2 is depicted in figure 10.
name_identifier形式0x2を図10に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Vendor Specific | OUI |
+-------+-------+---------------+---------------+---------------+
| OUI | VSID |
+---------------+---------------+---------------+---------------+
Fig. 10: Format 0x2 Name_Identifier
図10：フォーマット0x2 name_identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 11 [FC-FS].
このname_identifierから派生したEUI-64アドレスには、図11 [FC-FS]に示されている形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 11: EUI-64 Address from a Format 0x2 Name_Identifier
図11：フォーマット0x2 name_identifierのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 12.
IPv6インターフェイス識別子は、OUIフィールドのU/Lビットを補完することにより、このEUI-64アドレスから取得されます。したがって、IPv6インターフェイスIDのOUIは、FC name_identifierとまったく同じです。結果のIPv6インターフェイス識別子には、ローカルスコープ[AARCH]と図12に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 0 1 0| VSID |
+---------------+-----------------------+-------+-------+-------+
| VSID | Vendor Specific |
+---------------+-----------------------+-------+---------------+
Fig. 12: IPv6 Interface ID from a Format 0x2 Name_Identifier
図12：フォーマット0x2 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x27-89-34-63-46-AB-CD-EF generates the IPv6 Interface Identifier 3463:462A:BCDE:F789.
例として、FC name_identifier 0x27-89-34-63-46-ab-cd-efは、IPv6インターフェイス識別子3463：462A：BCDE：F789を生成します。
The Name_Identifier format 0x5 is depicted in figure 13.
name_identifier形式0x5を図13に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OUI | VSID |
+-------+-------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 13: Format 0x5 Name_Identifier
図13：フォーマット0x5 name_identifier
The EUI-64 address derived from this Name_Identifier has the format depicted in figure 14 [FC-FS].
このname_identifierから派生したEUI-64アドレスには、図14 [FC-FS]に示されている形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI with complemented U/L bit |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 14: EUI-64 Address from a Format 0x5 Name_Identifier
図14：FORMAT 0x5 name_identifierのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address complementing the U/L bit in the OUI field. So the OUI in the IPv6 Interface ID is exactly as in the FC Name_Identifier. The resulting IPv6 Interface Identifier has local scope [AARCH] and the format depicted in figure 15.
IPv6インターフェイス識別子は、OUIフィールドのU/Lビットを補完するこのEUI-64アドレスから取得されます。したがって、IPv6インターフェイスIDのOUIは、FC name_identifierとまったく同じです。結果のIPv6インターフェイス識別子には、ローカルスコープ[AARCH]と図15に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |0 1 0 1| VSID |
+---------------+---------------+---------------+-------+-------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 15: IPv6 Interface ID from a Format 0x5 Name_Identifier
図15：フォーマット0x5 name_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0x53-46-34-6A-BC-DE-F7-89 generates the IPv6 Interface Identifier 3463:465A:BCDE:F789.
例として、FC name_identifier 0x53-46-34-6a-bc-de-f7-89は、IPv6インターフェイス識別子3463：465a：BCDE：F789を生成します。
The EUI-64 mapped Name_Identifiers formats (formats 0xC through 0xF) are derived from an EUI-64 address by compressing the OUI field of such addresses. The compression is performed by removing from the OUI the Universal/Local and Individual/Group bits, and by putting bits 0 to 5 of the OUI in the first octet of the Name_Identifier, and bits 8 to 23 of the OUI in the second and third octet of the Name_Identifier, as shown in figure 16.
EUI-64マッピングされたNAME_IDENTIFIERSフォーマット（フォーマット0XCから0xF）は、そのようなアドレスのOUIフィールドを圧縮することにより、EUI-64アドレスから派生します。圧縮は、OUIからユニバーサル/ローカルおよび個人/グループのビットを除去し、name_identifierの最初のオクテットにOUIの0〜5を、2番目と3番目のOUIの8〜23を除去することによって実行されます。図16に示すように、name_identifierのオクテット。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| OUI[0..5] | OUI[8..23] | VSID |
+---+-----------+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 16: EUI-64 Mapped Name_Identifiers Format
図16：EUI-64マッピングNAME_IDENTIFIERS形式
The EUI-64 address used to generate the Name_Identifier shown in figure 16 has the format depicted in figure 17.
図16に示すname_identifierを生成するために使用されるEUI-64アドレスには、図17に示されている形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |0 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 17: EUI-64 Address from an EUI-64 Mapped Name_Identifier
図17：EUI-64マッピングされたname_identifierからのEUI-64アドレス
The IPv6 Interface Identifier is obtained from this EUI-64 address by complementing the U/L bit in the OUI field. The resulting IPv6 Interface Identifier has global scope [AARCH] and the format depicted in figure 18.
IPv6インターフェイス識別子は、OUIフィールドのU/Lビットを補完することにより、このEUI-64アドレスから取得されます。結果のIPv6インターフェイス識別子には、グローバルスコープ[AARCH]と図18に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI[0..5] |1 0| OUI[8..23] | VSID |
+-----------+---+---------------+---------------+---------------+
| VSID |
+---------------+---------------+---------------+---------------+
Fig. 18: IPv6 Interface ID from an EUI-64 Mapped Name_Identifier
図18：EUI-64マッピングname_identifierからのIPv6インターフェイスID
As an example, the FC Name_Identifier 0xCD-63-46-AB-01-25-78-9A generates the IPv6 Interface Identifier 3663:46AB:0125:789A.
例として、FC name_identifier 0xcd-63-46-AB-01-25-78-9aは、IPv6インターフェイス識別子3663：46AB：0125：789aを生成します。
The IPv6 link-local address [AARCH] for an Nx_Port is formed by appending the Interface Identifier, as defined in section 6, to the prefix FE80::/64. The resulting address is depicted in figure 19.
NX_PORTのIPv6リンクローカルアドレス[AARCH]は、セクション6で定義されているように、インターフェイス識別子をプレフィックスFE80 ::/64に追加することにより形成されます。結果のアドレスを図19に示します。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Fig. 19: IPv6 link-local Address Format
図19：IPv6リンクローカルアドレス形式
An Nx_Port has two kinds of Fibre Channel addresses:
NX_PORTには2種類のファイバーチャネルアドレスがあります。
- a non-volatile 64-bit address, called N_Port_Name; - a volatile 24-bit address, called N_Port_ID.
- n_port_nameと呼ばれる不揮発性64ビットアドレス。-N_PORT_IDと呼ばれる揮発性24ビットアドレス。
The N_Port_Name is used to uniquely identify the Nx_Port, while the N_Port_ID is used to route frames to the Nx_Port. Both FC addresses are required to resolve an IPv6 unicast address. The fact that the N_Port_ID is volatile implies that an Nx_Port MUST validate the mapping between its N_Port_Name and N_Port_ID when certain Fibre Channel events occur (see Appendix B).
N_PORT_NAMEはNX_PORTを一意に識別するために使用され、N_PORT_IDはフレームをNX_PORTにルーティングするために使用されます。IPv6ユニキャストアドレスを解決するには、両方のFCアドレスが必要です。N_PORT_IDが揮発性であるという事実は、特定のファイバーチャネルイベントが発生した場合、NX_PORTがN_PORT_NAMEとN_PORT_IDの間のマッピングを検証する必要があることを意味します（付録Bを参照）。
The procedure for mapping IPv6 unicast addresses into Fibre Channel link-layer addresses uses the Neighbor Discovery Protocol [DISC]. The Source/Target Link-layer Address option has the format depicted in figure 20 when the link layer is Fibre Channel.
IPv6ユニキャストアドレスをファイバーチャネルリンク層アドレスにマッピングする手順では、近隣ディスカバリープロトコル[disc]を使用します。ソース/ターゲットリンクレイヤーアドレスオプションには、リンクレイヤーがファイバーチャネルである場合の図20に示す形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Reserved |
+---------------+---------------+---------------+---------------+
| |
+- N_Port_Name -+
| |
+---------------+---------------+---------------+---------------+
| Reserved | N_Port_ID |
+---------------+---------------+---------------+---------------+
Fig. 20: Source/Target Link-layer Address option for Fibre Channel
図20：ファイバーチャネルのソース/ターゲットリンク層アドレスオプション
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
タイプ：ソースリンク層アドレスの場合。2ターゲットリンク層アドレスの場合。
Length: 2 (in units of 8 octets).
長さ：2（8オクテットの単位）。
N_Port_Name: This field contains the Nx_Port's N_Port_Name. N_Port_ID: This field contains the Nx_Port's N_Port_ID.
N_PORT_NAME：このフィールドには、NX_PORTのN_PORT_NAMEが含まれています。N_PORT_ID：このフィールドには、NX_PORTのN_PORT_IDが含まれています。
Reserved fields MUST be zero when transmitting, and MUST be ignored when receiving.
予約済みフィールドは送信時にゼロでなければならず、受信するときは無視する必要があります。
By default, all best-effort IPv6 multicast packets MUST be mapped to FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In particular, datagrams addressed to all-nodes multicast address, all-routers multicast address, and solicited-node multicast addresses [AARCH] MUST be sent as Class 3 FC Sequences addressed to the broadcast N_Port_ID 0xFF-FF-FF. In this case, the Destination N_Port_Name field of the FC Network_Header MUST be set to the value 0x10-00-FF-FF-FF-FF-FF-FF. Appendix A specifies how to transmit a Class 3 broadcast FC Sequence over various Fibre Channel topologies.
デフォルトでは、すべてのBest-Effort IPv6マルチキャストパケットは、ブロードキャストn_port_id 0xff-ff-ffにアドレス指定されたFCシーケンスにマッピングする必要があります。特に、All-Nodesマルチキャストアドレス、All-Routers Multicastアドレス、および勧誘されたマルチキャストアドレス[AARCH]に宛てられたデータグラムは、ブロードキャストN_PORT_ID 0xff-FF-FFにアドレス指定されたクラス3 FCシーケンスとして送信する必要があります。この場合、FC Network_Headerの宛先N_PORT_NAMEフィールドは、値0x10-00-FF-FF-FF-FF-FF-FFに設定する必要があります。付録Aでは、さまざまなファイバーチャネルトポロジを介してクラス3ブロードキャストFCシーケンスを送信する方法を示します。
An Nx_Port supporting IPv6 MUST be able to map a received broadcast Class 3 Device_Data FC frame to an implicit Port Login context in order to handle IPv6 multicast packets. The receive data field size of this implicit Port Login MUST be the same across all the Nx_Ports connected to the same Fabric, otherwise FC broadcast transmission does not work. In order to reduce the need for FC Sequence segmentation, the receive data field size of this implicit Port Login SHOULD be 1024 octets. This receive data field size requirement applies to broadcast Device_Data FC frames, not to ELSs.
IPv6をサポートするNX_PORTサポートIPv6は、IPv6マルチキャストパケットを処理するために、受信したブロードキャストクラス3 Device_Data FCフレームを暗黙のポートログインコンテキストにマッピングできる必要があります。この暗黙のポートログインの受信データフィールドサイズは、同じファブリックに接続されたすべてのNX_PORTSで同じでなければなりません。そうしないと、FCブロードキャスト伝送は機能しません。FCシーケンスセグメンテーションの必要性を減らすために、この暗黙のポートログインの受信データフィールドサイズは1024オクテットでなければなりません。この受信データフィールドサイズの要件は、ELSではなく、Device_Data FCフレームをブロードキャストすることに適用されます。
Receiving an FC Sequence carrying an IPv6 multicast packet MAY trigger some additional processing by the Nx_Port if that IPv6 packet requires a unicast reply. In this case, if a valid Port Login to the Nx_Port that sent the IPv6 multicast packet does not exist, the Nx_Port MUST perform such a Port Login, and then use it for the unicast IPv6 reply. In the case of Neighbor Discovery messages [DISC], the N_Port_ID to which the Port Login is directed is taken from the N_Port_ID field of the Source/Target Link-layer Address option.
IPv6パケットを運ぶIPv6マルチキャストパケットを運ぶFCシーケンスを受信すると、そのIPv6パケットにユニキャスト応答が必要な場合、NX_PORTによる追加の処理がトリガーされる場合があります。この場合、IPv6マルチキャストパケットを送信したNX_PORTへの有効なポートログインが存在しない場合、NX_PORTはそのようなポートログインを実行し、ユニキャストIPv6応答に使用する必要があります。Neighbor Discoveryメッセージ[DISC]の場合、ポートログインが誘導されるN_PORT_IDは、ソース/ターゲットリンクレイヤーアドレスオプションのN_PORT_IDフィールドから取得されます。
As an example, an Nx_Port processes a received broadcast FC Sequence carrying an IPv6 multicast unsolicited router advertisement [DISC] simply by passing the carried IPv6 packet to the IPv6 layer. Instead, if a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a unicast reply, and no valid Port Login exists with the Nx_Port sender of the multicast packet, then a Port Login MUST be performed in order to send the unicast reply message. If a received broadcast FC Sequence carries an IPv6 multicast solicitation message [DISC] requiring a multicast reply, the reply is sent to the broadcast N_Port_ID 0xFF-FF-FF.
例として、NX_PORTは、CARRIED IPv6パケットをIPv6レイヤーに渡すだけで、IPv6マルチキャスト未承諾ルーター広告[disc]を運ぶ受信したブロードキャストFCシーケンスを処理します。代わりに、受信したブロードキャストFCシーケンスにIPv6マルチキャスト勧誘メッセージ[disc]がユニキャスト応答を必要とする場合、マルチキャストパケットのNX_port送信者には有効なポートログインが存在しない場合は、ユニキャストを送信するためにポートログインを実行する必要があります。返信メッセージ。受信したブロードキャストFCシーケンスには、マルチキャストの返信が必要なIPv6マルチキャスト勧誘メッセージ[disc]が含まれている場合、返信はブロードキャストn_port_id 0xff-ff-ffに送信されます。
Best-effort IPv6 multicast for other multicast group addresses MAY use Fibre Channel Multicast Groups [FC-FS], if supported by the particular FC topology and implementation.
他のマルチキャストグループアドレス用のベストエフォルトIPv6マルチキャストは、特定のFCトポロジと実装でサポートされている場合、ファイバーチャネルマルチキャストグループ[FC-FS]を使用する場合があります。
FC Sequences are REQUIRED to be non-streamed. In order to avoid missing FC frame aliasing by Sequence_ID reuse, an Nx_Port supporting IPv6 is REQUIRED to use continuously increasing SEQ_CNT [FC-FS]. Each Exchange MUST start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that MUST increment the previous SEQ_CNT by one. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
FCシーケンスは非ストリーミングを行う必要があります。Sequence_idの再利用によるFCフレームエイリアシングの欠落を避けるために、継続的に増加するSEQ_CNT [FC-FS]を使用するには、NX_PORTをサポートするIPv6をサポートする必要があります。各交換は、最初のフレームでSEQ_CNT = 0から開始する必要があり、その後送信されたすべてのフレームは、以前のSEQ_CNTを1つずつ増分する必要があります。交換中の他のN_PORTから受け取ったフレームは、送信されたSEQ_CNTに影響を与えません。
To transfer IPv6 packets, each Nx_Port MUST have a dedicated Exchange for sending data to each Nx_Port in the network and a dedicated Exchange for receiving data from each Nx_Port.
IPv6パケットを転送するには、各NX_PORTには、ネットワーク内の各NX_PORTにデータを送信するための専用の交換と、各NX_PORTからデータを受信するための専用交換が必要です。
An Exchange Responder is not required to assign RX_IDs. If an RX_ID of 0xFFFF is assigned, the Exchange Responder is identifying Exchanges based on S_ID / D_ID / OX_ID only.
rx_idsを割り当てるために交換リスポンダーは必要ありません。0xffffのRX_IDが割り当てられている場合、Exchange ResponderはS_ID / D_ID / OX_IDのみに基づいて交換を識別しています。
When an Exchange is created between two Nx_Ports for unicast IPv6 packets, it remains active while the Nx_Ports are logged in with each other. Each FC broadcast and ELS [FC-FS] SHOULD use a separate short lived Exchange.
ユニキャストIPv6パケットの2つのNX_PORTSの間に交換が作成されると、NX_PORTSが互いにログインしている間、アクティブのままです。各FCブロードキャストとELS [FC-FS]は、別の短命の交換を使用する必要があります。
For IPv6, Exchanges MUST NOT transfer Sequence Initiative, because they are used in a unidirectional mode. The Sequence Initiative bit in the F_CTL field of the FC Header [FC-FS] MUST be set to 0.
IPv6の場合、交換は単方向モードで使用されるため、シーケンスイニシアチブを転送してはなりません。FCヘッダー[FC-FS]のF_CTLフィールドにあるシーケンスイニシアチブビットは、0に設定する必要があります。
The mechanism for aging or expiring exchanges based on activity, timeout, or other methods is outside the scope of this document.
アクティビティ、タイムアウト、またはその他の方法に基づいた老化または期限切れの交換のメカニズムは、このドキュメントの範囲外です。
The Exchange Originator MAY terminate Exchanges by setting the F_CTL LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator or Exchange Responder by using the ABTS (Abort Sequence) protocol [FC-FS]. IPv6 Exchanges SHOULD NOT be terminated by Logout, since this may terminate active Exchanges on other FC-4s [FC-FS].
Exchange Originatorは、F_CTL LSビット[FC-FS]を設定することにより、交換を終了できます。交換は、ABTS（Abort Sequence）プロトコル[FC-FS]を使用して、Exchange OriginatorまたはExchange Responderによって取り壊される場合があります。IPv6交換は、ログアウトによって終了するべきではありません。これは、他のFC-4 [FC-FS]のアクティブな交換を終了する可能性があるためです。
IPv6 does not introduce any additional security concerns beyond those that already exist within the Fibre Channel protocols. Zoning techniques based on FC Name Server masking (soft zoning) do not work with IPv6, because IPv6 over Fibre Channel does not use the FC Name Server. The FC ESP_Header [FC-FS] may be used to secure the FC frames composing FC Sequences carrying IPv6 packets. All the techniques defined to secure IPv6 traffic at the IPv6 layer may be used in a Fibre Channel environment.
IPv6は、ファイバーチャネルプロトコル内に既に存在するものを超えて、追加のセキュリティ上の懸念を導入していません。FC Name Serverマスキング（ソフトゾーニング）に基づくゾーニング技術は、IPv6では機能しません。FCNameServerを使用していないため、IPv6では機能しません。FC ESP_Header [FC-FS]を使用して、IPv6パケットを運ぶFCシーケンスを構成するFCフレームを保護することができます。IPv6層でIPv6トラフィックを保護するために定義されたすべての手法は、ファイバーチャネル環境で使用できます。
The author would like to acknowledge the authors of [IPFC], [ETHER], and [IPv6-1394], since some part of this document has been derived from them, as well as the ANSI INCITS T11.3 Task Group members who reviewed this document.
著者は、このドキュメントの一部がそれらから派生しているため、[IPFC]、[Ether]、および[IPv6-1394]の著者と、レビューしたANSIがT11.3タスクグループメンバーを挿入したため、確認したいと考えています。このドキュメント。
[FC-FS] ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)".
[FC-FS] ANSIは373-2003、「ファイバーチャネル - フレーミングとシグナリング（FC-FS）」を挿入します。
[FC-AL-2] ANSI INCITS 332-1999, "Fibre Channel - Arbitrated Loop-2 (FC-AL-2)".
[FC-AL-2] ANSIは332-1999、「ファイバーチャネル - 任意ループ2（FC-AL-2）」を挿入します。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[Aarch] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アーキテクチャのアドレス指定」、RFC 3513、2003年4月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[disc] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTUD] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture".
[IEEE-LLC] IEEE STD 802-2001、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[IPFC] Rajagopal、M.、Bhagwat、R。、およびW. Rickard、「IP and ARP Over Fiber Channel」、RFC 2625、1999年6月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html
[EUI64]「64ビットグローバル識別子（EUI-64）のガイドライン」、http：//standards.ieee.org/db/oui/tutorials/eui64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ether] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
[IPv6-1394] Fujisawa、K。およびA. Onoe、「IEEE 1394ネットワーク上のIPv6パケットの送信」、RFC 3146、2001年10月。
A. Transmission of a Broadcast FC Sequence over FC Topologies
A. FCトポロジを介したブロードキャストFCシーケンスの送信
No particular mechanisms are required for this case. The Nx_Port connected at the other side of the cable receives the broadcast FC Sequence having D_ID 0xFFFFFF.
このケースには特定のメカニズムは必要ありません。ケーブルの反対側で接続されているNX_PORTは、D_ID 0xffffffを持つブロードキャストFCシーケンスを受信します。
An NL_Port attached to a private loop MUST transmit a Class 3 broadcast FC Sequence by using the OPN(fr) primitive signal [FC-AL-2].
プライベートループに接続されたNL_PORTは、OPN（FR）プリミティブ信号[FC-AL-2]を使用して、クラス3ブロードキャストFCシーケンスを送信する必要があります。
a) The source NL_Port first sends an Open Broadcast Replicate (OPN(fr)) primitive signal, forcing all the NL_Ports in the loop (except itself) to replicate the frames that they receive while examining the FC Header's D_ID field. b) The source NL_Port then removes the OPN(fr) signal when it returns to it. c) The source NL_Port then sends the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF.
a) Source NL_PORTは、最初にオープンブロードキャスト複製（OPN（FR））プリミティブ信号を送信し、ループ内のすべてのNL_PORTSを強制して、FCヘッダーのD_IDフィールドを調べながら受信したフレームを複製します。b）ソースNL_PORTは、OPN（FR）信号を返すと削除します。c）ソースNL_PORTは、D_ID 0xFFFFFFを備えたクラス3ブロードキャストFCシーケンスを送信します。
An NL_Port attached to a public loop MUST NOT use the OPN(fr) primitive signal. Rather, it MUST send the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00 [FC-AL-2].
パブリックループに接続されたNL_PORTは、OPN（FR）プリミティブ信号を使用してはなりません。むしろ、d_id 0xffffffを使用したクラス3ブロードキャストFCシーケンスをal_pa = 0x00 [fc-al-2]のfl_portに送信する必要があります。
The Fabric propagates the broadcast to all other FC_Ports [FC-FS], including the FL_Port which the broadcast arrives on. This includes all F_Ports, and other FL_Ports.
生地は、ブロードキャストが到着するFL_PORTを含む、他のすべてのFC_PORTS [FC-FS]にブロードキャストを伝播します。これには、すべてのf_ports、およびその他のfl_portsが含まれます。
Each FL_Port propagates the broadcast by using the primitive signal OPN(fr), in order to prepare the loop to receive the broadcast sequence.
各FL_PORTは、ブロードキャストシーケンスを受信するためにループを準備するために、プリミティブ信号OPN（FR）を使用してブロードキャストを伝播します。
An N_Port connected to an F_Port MUST transmit the Class 3 broadcast FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric propagates the broadcast to all other FC_Ports [FC-FS].
f_portに接続されたN_portは、d_id 0xffffffをf_portにd_id 0xffffffを持つクラス3ブロードキャストFCシーケンスを送信する必要があります。生地は、他のすべてのFC_PORTS [FC-FS]にブロードキャストを伝播します。
B. Validation of the <N_Port_Name, N_Port_ID> mapping
B. <n_port_name、n_port_id>マッピングの検証
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid before use.
常に、<n_port_name、n_port_id>マッピングは使用する前に有効でなければなりません。
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may change, as well as the N_Port_IDs of all other Nx_Ports that have previously performed Port Login with this Nx_Port. Because of this, address validation is required after a LIP in a loop topology [FC-AL-2] or after NOS/OLS in a point-to-point topology [FC-FS].
FCリンクの中断が発生した後、NX_PORTのN_PORT_IDが変更される場合があり、以前にこのNX_PORTでポートログインを実行した他のすべてのNX_PORTのN_PORT_IDが変更される場合があります。このため、ループトポロジのリップ[FC-AL-2]またはポイントツーポイントトポロジー[FC-FS]のNOS/OLSの後にアドレス検証が必要です。
N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS], thus address validation is not required in this case.
N_PORT_IDSは、リンクリセット（LR）[FC-FS]の結果として変更されないため、この場合はアドレス検証は必要ありません。
No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each N_Port and after a NOS/OLS each N_Port must again perform a Port Login [FC-FS].
LR後に検証は必要ありません。ポイントツーポイントトポロジでは、NOS/OLSは各N_PORTの暗黙的なログアウトを引き起こし、NOS/OLSの後に各N_PORTが再びポートログイン[FC-FS]を実行する必要があります。
After a LIP [FC-AL-2], an NL_Port must not transmit any data to another NL_Port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC [FC-FS].
リップ[FC-AL-2]の後、NL_PORTは、他のポートのアドレスが検証されるまで、データを別のNL_PORTに送信してはなりません。検証は、ADISCまたはPDISC [FC-FS]のいずれかを完了することで構成されています。
For a requester, this specification prohibits PDISC and requires ADISC. As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
要求者の場合、この仕様はPDISCを禁止し、Adiscが必要です。応答者として、実装は、他のFC仕様との互換性のためにADISCとPDISCの両方に応答する必要がある場合があります。
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a logged remote NL_Port exactly match the values prior to the LIP, then any active Exchange with that NL_Port may continue.
ログされたリモートNL_PORTの3つのFCアドレス（n_port_id、n_port_name、node_name）が、唇の前に値と正確に一致する場合、そのnl_portとのアクティブな交換は続く場合があります。
If any of the three FC addresses has changed, then the remote NL_Port must be logged out.
3つのFCアドレスのいずれかが変更された場合、リモートNL_PORTをログアウトする必要があります。
If an NL_Port's N_Port_ID changes after a LIP, then all active logged in NL_Ports must be logged out.
nl_portのn_port_idがリップの後に変更された場合、NL_PORTSですべてのアクティブログに記録する必要があります。
A FAN ELS may be sent by the Fabric to all known previously logged in NL_Ports following an initialization event. Therefore, after a LIP [FC-AL-2], NL_Ports may wait for this notification to arrive, or they may perform an FLOGI.
ファンELSは、初期化イベントに続いて、NL_PORTSでログインしていたすべての既知のすべてに生地から送信される場合があります。したがって、唇[FC-AL-2]の後、NL_PORTSはこの通知が到着するのを待つか、フロギを実行する可能性があります。
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI response exactly match the values before the LIP and if the AL_PA [FC-AL-2] obtained by the NL_Port is the same as the one before the LIP, then the port may resume all Exchanges. If not, then FLOGI must be performed with the Fabric and all logged in Nx_Ports must be logged out.
ファンELSまたはFLOGI応答に含まれるF_PORT_NAMEおよびFABRIC_NAMEが唇の前の値と正確に一致し、NL_PORTによって取得されたAL_PA [FC-AL-2]が唇の前のものと同じ場合、ポートは再開できますすべての交換。そうでない場合は、Flogiをファブリックで実行する必要があり、NX_PORTSですべてのログインしてログアウトする必要があります。
A public loop NL_Port must perform the private loop validation as specified in section B.3 to any NL_Port on the local loop that has an N_Port_ID of the form 0x00-00-XX.
パブリックループNL_PORTは、セクションB.3で指定されたプライベートループ検証を、フォーム0x00-00-XXのN_PORT_IDを持つローカルループ上の任意のNL_PORTに実行する必要があります。
No validation is required after LR (link reset).
LR（リンクリセット）後に検証は必要ありません。
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the N_Port's N_Port_ID, the F_Port_Name, and the Fabric_Name are the same as before the NOS/OLS, then the N_Port may resume all Exchanges. If not, all logged in Nx_Ports must be logged out [FC-FS].
NOS/OLSの後、N_PORTはFLOGIを実行する必要があります。Flogiの後、N_PORTのN_PORT_ID、F_PORT_NAME、およびFABRIC_NAMEがNOS/OLSの前と同じ場合、N_PORTはすべての交換を再開する場合があります。そうでない場合、NX_PORTSでログインしたすべてのログアウトをログアウトする必要があります[FC-FS]。
C. Fibre Channel Bit and Byte Numbering Guidance
C.ファイバーチャネルビットとバイト番号のガイダンス
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit numbering is different.
ファイバーチャネルとIETF標準の両方が同じバイト伝送順序を使用します。ただし、ビット番号は異なります。
Fibre Channel bit numbering can be observed if the data structure heading shown in figure 21 is cut and pasted at the top of the figures present in this document.
図21に示すデータ構造の見出しが、このドキュメントに存在する図の上部に貼り付けられて貼り付けられている場合、ファイバーチャネルビット番号が観察できます。
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
図21：ファイバーチャネルビット番号付け
Author's Address
著者の連絡先
Claudio DeSanti Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Claudio Desanti Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134 USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。