RFC4172 日本語訳
4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking.C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards. September 2005. (Format: TXT=241908 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Monia
Request for Comments: 4172 Consultant
Category: Standards Track R. Mullendore
McDATA
F. Travostino
Nortel
W. Jeong
Troika Networks
M. Edwards
Adaptec (UK) Ltd.
September 2005
Moniaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4172年のコンサルタントカテゴリ: 規格はM.エドワーズAdaptec(イギリス)株式会社2005年9月にR.Mullendore McDATA F.TravostinoノーテルW.Jeongトロイカネットワークを追跡します。
iFCP - A Protocol for Internet Fibre Channel Storage Networking
iFCP--インターネット繊維河道貯留ネットワークのためのプロトコル
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
このドキュメントはIPネットワークの上で繊維チャンネル骨組みの機能性の実装にアーキテクチャとゲートウェー間プロトコルを指定します。 TCPプロトコルを通して繊維チャンネル規格によって指定された繊維チャンネルフレーム輸送と分配された骨組みのサービスにこの機能性を提供します。 アーキテクチャはゲートウェイでアクセスされた領域を通って自律システムの欠点分離の特性とIPネットワークのスケーラビリティで繊維チャンネルデバイスのインターネットワーキングを可能にします。
Table of Contents
目次
1. Introduction.................................................. 4
1.1. Conventions used in This Document....................... 4
1.1.1. Data Structures Internal to an Implementation... 4
1.2. Purpose of This Document................................ 4
2. iFCP Introduction............................................. 4
2.1. Definitions............................................. 5
3. Fibre Channel Communication Concepts.......................... 7
3.1. The Fibre Channel Network............................... 8
1. 序論… 4 1.1. This Documentで中古のコンベンション… 4 1.1.1. 実装への…内部のデータ構造 4 1.2. このドキュメントの目的… 4 2. iFCP序論… 4 2.1. 定義… 5 3. 繊維チャンネルコミュニケーション概念… 7 3.1. 繊維チャンネルネットワーク… 8
Monia, et al. Standards Track [Page 1] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[1ページ]RFC4172インターネット繊維チャンネル
3.2. Fibre Channel Network Topologies........................ 9
3.2.1. Switched Fibre Channel Fabrics.................. 11
3.2.2. Mixed Fibre Channel Fabric...................... 12
3.3. Fibre Channel Layers and Link Services.................. 12
3.3.1. Fabric-Supplied Link Services................... 13
3.4. Fibre Channel Nodes..................................... 14
3.5. Fibre Channel Device Discovery.......................... 14
3.6. Fibre Channel Information Elements...................... 15
3.7. Fibre Channel Frame Format.............................. 15
3.7.1. N_PORT Address Model............................ 16
3.8. Fibre Channel Transport Services........................ 17
3.9. Login Processes......................................... 18
4. The iFCP Network Model........................................ 18
4.1. iFCP Transport Services................................. 21
4.1.1. Fibre Channel Transport Services Supported by
iFCP............................................ 21
4.2. iFCP Device Discovery and Configuration Management...... 21
4.3. iFCP Fabric Properties.................................. 22
4.3.1. Address Transparency............................ 22
4.3.2. Configuration Scalability....................... 23
4.3.3. Fault Tolerance................................. 23
4.4. The iFCP N_PORT Address Model........................... 24
4.5. Operation in Address Transparent Mode................... 25
4.5.1. Transparent Mode Domain ID Management........... 26
4.5.2. Incompatibility with Address Translation Mode... 26
4.6. Operation in Address Translation Mode................... 27
4.6.1. Inbound Frame Address Translation............... 28
4.6.2. Incompatibility with Address Transparent Mode... 29
5. iFCP Protocol................................................. 29
5.1. Overview ............................................... 29
5.1.1. iFCP Transport Services......................... 29
5.1.2. iFCP Support for Link Services.................. 30
5.2. TCP Stream Transport of iFCP Frames..................... 30
5.2.1. iFCP Session Model.............................. 30
5.2.2. iFCP Session Management......................... 31
5.2.3. Terminating iFCP Sessions....................... 39
5.3. Fibre Channel Frame Encapsulation....................... 40
5.3.1. Encapsulation Header Format..................... 41
5.3.2. SOF and EOF Delimiter Fields.................... 44
5.3.3. Frame Encapsulation............................. 45
5.3.4. Frame De-encapsulation.......................... 46
6. TCP Session Control Messages.................................. 47
6.1. Connection Bind (CBIND)................................. 50
6.2. Unbind Connection (UNBIND).............................. 52
6.3. LTEST -- Test Connection Liveness....................... 54
7. Fibre Channel Link Services................................... 55
7.1. Special Link Service Messages........................... 56
7.2. Link Services Requiring Payload Address Translation..... 58
3.2. 繊維チャンネルネットワークTopologies… 9 3.2.1. 繊維チャンネル骨組みを切り換えます… 11 3.2.2. Mixed繊維は骨組みを向けます… 12 3.3. 繊維チャンネル層とリンクサービス… 12 3.3.1. 骨組みに供給されたリンクサービス… 13 3.4. 繊維チャンネルノード… 14 3.5. 繊維チャンネルデバイス発見… 14 3.6. 繊維経路情報要素… 15 3.7. 繊維チャンネルフレーム形式… 15 3.7.1. N_ポートアドレスモデル… 16 3.8. 繊維チャンネル輸送サービス… 17 3.9. ログインは処理されます… 18 4. iFCPはモデルをネットワークでつなぎます… 18 4.1iFCPはサービスを輸送します… 21 4.1.1. iFCPによってサポートされた繊維チャンネル輸送サービス… 21 4.2 iFCPデバイス発見と構成管理… 21 4.3iFCP骨組みの特性… 22 4.3.1. 透明を扱ってください… 22 4.3.2. 構成スケーラビリティ… 23 4.3.3. 欠点寛容… 23 4.4. iFCP N_ポートアドレスモデル… 24 4.5. アドレス透過モードにおける操作… 25 4.5.1. 透過モードドメインID管理… 26 4.5.2. アドレス変換モードがある…不一致 26 4.6. アドレス変換モードにおける操作… 27 4.6.1. 本国行きのフレームアドレス変換… 28 4.6.2. アドレス透過モードがある…不一致 29 5iFCPは議定書を作ります… 29 5.1. 概要… 29 5.1.1iFCPはサービスを輸送します… 29 5.1.2iFCPはリンクにサービスをサポートします… 30 5.2. TCPはiFCPフレームの輸送を流します… 30 5.2.1iFCPセッションモデル… 30 5.2.2iFCPセッション管理… 31 5.2.3. iFCPセッションを終えます… 39 5.3. 繊維チャンネルフレームカプセル化… 40 5.3.1. カプセル化ヘッダー形式… 41 5.3.2. SOFとEOFデリミタ分野… 44 5.3.3. カプセル化を縁どってください… 45 5.3.4. 反-カプセル化を縁どってください… 46 6. TCPセッション制御メッセージ… 47 6.1. 接続ひもの(CBIND)… 50 6.2. 接続(解く)を解いてください… 52 6.3. LTEST--接続活性をテストしてください… 54 7. 繊維チャンネルリンクサービス… 55 7.1. 特別なリンクサービスメッセージ… 56 7.2. 有効搭載量アドレス変換を必要とするサービスをリンクしてください… 58
Monia, et al. Standards Track [Page 2] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[2ページ]RFC4172インターネット繊維チャンネル
7.3. Fibre Channel Link Services Processed by iFCP........... 61
7.3.1. Special Extended Link Services.................. 63
7.3.2. Special FC-4 Link Services...................... 83
7.4. FLOGI Service Parameters Supported by an iFCP Gateway... 84
8. iFCP Error Detection.......................................... 86
8.1. Overview................................................ 86
8.2. Stale Frame Prevention.................................. 86
8.2.1. Enforcing R_A_TOV Limits........................ 86
9. Fabric Services Supported by an iFCP Implementation........... 88
9.1. F_PORT Server........................................... 88
9.2. Fabric Controller....................................... 89
9.3. Directory/Name Server................................... 89
9.4. Broadcast Server........................................ 89
9.4.1. Establishing the Broadcast Configuration........ 90
9.4.2. Broadcast Session Management.................... 91
9.4.3. Standby Global Broadcast Server................. 91
10. iFCP Security................................................. 91
10.1. Overview................................................ 91
10.2. iFCP Security Threats and Scope......................... 92
10.2.1. Context......................................... 92
10.2.2. Security Threats................................ 92
10.2.3. Interoperability with Security Gateways......... 93
10.2.4. Authentication.................................. 93
10.2.5. Confidentiality................................. 93
10.2.6. Rekeying........................................ 93
10.2.7. Authorization................................... 94
10.2.8. Policy Control.................................. 94
10.2.9. iSNS Role....................................... 94
10.3. iFCP Security Design.................................... 94
10.3.1. Enabling Technologies........................... 94
10.3.2. Use of IKE and IPsec............................ 96
10.3.3. Signatures and Certificate-Based Authentication. 98
10.4. iSNS and iFCP Security.................................. 99
10.5. Use of iSNS to Distribute Security Policy............... 99
10.6. Minimal Security Policy for an iFCP Gateway............. 99
11. Quality of Service Considerations.............................100
11.1. Minimal Requirements....................................100
11.2. High Assurance..........................................100
12. IANA Considerations...........................................101
13. Normative References..........................................101
14. Informative References........................................103
Appendix A. iFCP Support for Fibre Channel Link Services.........105
A.1. Basic Link Services.....................................105
A.2. Pass-Through Link Services..............................105
A.3. Special Link Services...................................107
Appendix B. Supporting the Fibre Channel Loop Topology...........108
B.1. Remote Control of a Public Loop.........................108
Acknowledgements..................................................109
7.3. 繊維チャンネルリンクサービスはiFCPによって処理されました… 61 7.3.1. 特別な拡張リンクサービス… 63 7.3.2. 特別なFC-4はサービスをリンクします… 83 7.4. FLOGIはiFCPゲートウェイによってサポートされたパラメタを修理します… 84 8iFCP誤り検出… 86 8.1. 概要… 86 8.2. フレーム防止は聞き古したになってください… 86 8.2.1. R_A_TOV限界を実施します… 86 9. iFCP実装で後押しされている骨組みのサービス… 88 9.1. F_はサーバを移植します… 88 9.2. 骨組みのコントローラ… 89 9.3. ディレクトリ/ネームサーバ… 89 9.4. サーバを放送してください… 89 9.4.1. 放送構成を確立します… 90 9.4.2. セッション管理を放送してください… 91 9.4.3. 待機のグローバルな放送サーバ… 91 10. iFCPセキュリティ… 91 10.1. 概要… 91 10.2. iFCP軍事的脅威と範囲… 92 10.2.1. 文脈… 92 10.2.2. セキュリティの脅威… 92 10.2.3. セキュリティゲートウェイがある相互運用性… 93 10.2.4. 認証… 93 10.2.5. 秘密性… 93 10.2.6. Rekeyingします… 93 10.2.7. 承認… 94 10.2.8. 方針コントロール… 94 10.2.9. iSNSの役割… 94 10.3. iFCPセキュリティデザイン… 94 10.3.1. 技術を可能にします… 94 10.3.2. IKEとIPsecの使用… 96 10.3.3. 署名と証明書ベースの認証。 98 10.4. iSNSとiFCPセキュリティ… 99 10.5. 安全保障政策を分配するiSNSの使用… 99 10.6. iFCPゲートウェイへの最小量の安全保障政策… 99 11. サービスの質問題…100 11.1. 最小量の要件…100 11.2. 高い保証…100 12. IANA問題…101 13. 標準の参照…101 14. 有益な参照…103 付録A.iFCPは繊維チャンネルのためにリンクサービスをサポートします…105 A.1。 基本リンクサービス…105 A.2。 リンクサービスを通り抜けてください…105 A.3。 特別なリンクサービス…繊維チャンネルを支える107付録B.がトポロジーを輪にします…108 B.1。 公共の輪の遠隔操作…108の承認…109
Monia, et al. Standards Track [Page 3] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[3ページ]RFC4172インターネット繊維チャンネル
1. Introduction
1. 序論
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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 BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Unless specified otherwise, numeric quantities are given as decimal values.
別の方法で指定しない場合、デシマル値として数値量を与えます。
All diagrams that portray bit and byte ordering, including the depiction of structures defined by fibre channel standards, adhere to the IETF conventions whereby bit 0 is the most significant bit and the first addressable byte is in the upper left corner. This IETF convention differs from that used for INCITS T11 fibre channel standards, in which bit 0 is the least significant bit.
繊維チャンネル規格によって定義された構造の描写を含むビットとバイト順を描くすべてのダイヤグラムがビット0が最も重要なビットであり、最初のアドレス可能なバイトが左上隅にあるIETFコンベンションを固く守ります。 このIETFコンベンションはINCITS T11繊維チャンネル規格に使用されるそれと異なっています。そこでは、ビット0は最下位ビットです。
1.1.1. Data Structures Internal to an Implementation
1.1.1. 実装への内部のデータ構造
To facilitate the specification of required behavior, this document may define and refer to internal data structures within an iFCP implementation. Such structures are intended for explanatory purposes only and need not be instantiated within an implementation as described in this specification.
このドキュメントは、必要な振舞いの仕様を容易にするために、iFCP実装の中に内部のデータ構造を定義して、示すかもしれません。 そのような構造は、説明している目的だけのために意図して、この仕様で説明されるように実装の中に例示される必要はありません。
1.2. Purpose of This Document
1.2. このドキュメントの目的
This is a standards-track document that specifies a protocol for the implementation of fibre channel transport services on a TCP/IP network. Some portions of this document contain material from standards controlled by INCITS T10 and T11. This material is included here for informational purposes only. The authoritative information is given in the appropriate NCITS standards document.
これはTCP/IPネットワークで繊維チャンネル輸送サービスの実装にプロトコルを指定する標準化過程文書です。 このドキュメントのいくつかの一部がINCITS T10とT11によって制御された規格からの材料を含んでいます。 この材料は情報の目的だけのためにここに含まれています。 適切なNCITS規格文書で信頼できる情報を与えます。
The authoritative portions of this document specify the mapping of standards-compliant fibre channel protocol implementations to TCP/IP. This mapping includes sections of this document that describe the "iFCP Protocol" (see Section 5).
このドキュメントの正式の部分は規格対応することの繊維チャンネルプロトコル実装に関するマッピングをTCP/IPに指定します。 このマッピングは「iFCPプロトコル」について説明するこのドキュメントのセクションを含んでいます(セクション5を見てください)。
2. iFCP Introduction
2. iFCP序論
iFCP is a gateway-to-gateway protocol that provides fibre channel fabric services to fibre channel devices over a TCP/IP network. iFCP uses TCP to provide congestion control, error detection, and recovery. iFCP's primary objective is to allow interconnection and
iFCPは繊維チャンネルデバイスに対する繊維チャンネル骨組みのサービスをTCP/IPネットワークの上に提供するゲートウェー間プロトコルです。iFCPは、輻輳制御、誤り検出、および回復を供給するのにTCPを使用します。そしてiFCPの主目的がインタコネクトを許すことである。
Monia, et al. Standards Track [Page 4] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[4ページ]RFC4172インターネット繊維チャンネル
networking of existing fibre channel devices at wire speeds over an IP network.
ワイヤの既存の繊維チャンネルデバイスのネットワークはIPネットワークの上を疾走します。
The protocol and method of frame address translation described in this document permit the attachment of fibre channel storage devices to an IP-based fabric by means of transparent gateways.
アドレス変換が説明したフレームのプロトコルとメソッドは透明なゲートウェイによる本書では繊維チャンネル記憶装置の付属をIPベースの骨組みに可能にします。
The protocol achieves this transparency by allowing normal fibre channel frame traffic to pass through the gateway directly, with provisions, where necessary, for intercepting and emulating the fabric services required by a fibre channel device.
正常な繊維チャンネルフレームトラフィックが直接ゲートウェイを通り抜けるのを許容することによって、プロトコルはこの透明を実現します、条項で骨組みを妨害して、見習うのに、必要であるところでは、サービスが繊維チャンネルデバイスが必要です。
2.1. Definitions
2.1. 定義
Terms needed to describe the concepts presented in this document are presented here.
本書では提示された概念について説明するのに必要である用語はここに提示されます。
Address-translation mode -- A mode of gateway operation in which the
scope of N_PORT fabric addresses, for locally attached devices,
are local to the iFCP gateway region in which the devices reside.
アドレス変換モード--デバイスが住んでいるiFCPゲートウェイ領域へのPORT骨組みが局所的に添付のデバイスのために扱うN_の範囲がどれであるかの地方のゲートウェイ操作のモード。
Address-transparent mode -- A mode of gateway operation in which the
scope of N_PORT fabric addresses, for all fibre channel devices,
are unique to the bounded iFCP fabric to which the gateway
belongs.
アドレス見え透いたモード--PORT骨組みがすべての繊維チャンネルデバイスのために扱うN_の範囲がどれであるかでゲートウェイが属する境界があるiFCP骨組みにユニークなゲートウェイ操作のモード。
Bounded iFCP Fabric -- The union of two or more gateway regions
configured to interoperate in address-transparent mode.
境界があるiFCP Fabric--2つ以上のゲートウェイ領域の組合はアドレス見え透いたモードで共同利用するのを構成されました。
DOMAIN_ID -- The value contained in the high-order byte of a 24-bit
N_PORT fibre channel address.
DOMAIN_ID--値は24ビットのNの高位バイトに_PORT繊維チャンネル・アドレスを含みました。
F_PORT -- The interface used by an N_PORT to access fibre channel
switched-fabric functionality.
F_PORT--繊維チャンネル切り換えられた骨組みの機能性にアクセスするのにN_PORTによって使用されたインタフェース。
Fabric -- From [FC-FS]: "The entity that interconnects N_PORTs
attached to it and is capable of routing frames by using only the
address information in the fibre channel frame."
骨組み--[FC-FS]から: 「N_PORTsとインタコネクトする実体は、それに付いて、繊維チャンネルフレームでアドレス情報だけを使用することによって、ルーティングフレームができます。」
Fabric Port -- The interface through which an N_PORT accesses a fibre
channel fabric. The type of fabric port depends on the fibre
channel fabric topology. In this specification, all fabric port
interfaces are considered functionally equivalent.
骨組みのPort--N_PORTが繊維チャンネル骨組みにアクセスするインタフェース。 骨組みのポートのタイプは繊維チャンネル骨組みのトポロジーを当てにします。 この仕様では、すべての骨組みのポートインタフェースが機能上同等であると考えられます。
FC-2 -- The fibre channel transport services layer, described in
[FC-FS].
FC-2--繊維チャンネル輸送は[FC-FS]で説明された層を調整します。
Monia, et al. Standards Track [Page 5] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[5ページ]RFC4172インターネット繊維チャンネル
FC-4 -- The fibre channel mapping of an upper-layer protocol, such as
[FCP-2], the fibre channel to SCSI mapping.
FC-4--[FCP-2]、SCSIマッピングへの繊維チャンネルなどの上側の層のプロトコルに関する繊維チャンネルマッピング。
Fibre Channel Device -- An entity implementing the functionality
accessed through an FC-4 application protocol.
繊維Channel Device--FC-4アプリケーション・プロトコルを通してアクセスされた機能性を実装する実体。
Fibre Channel Network -- A native fibre channel fabric and all
attached fibre channel nodes.
繊維Channel Network--自然な繊維チャンネル骨組みとすべてが繊維チャンネルノードを添付しました。
Fibre Channel Node -- A collection of one or more N_PORTs controlled
by a level above the FC-2 layer. A node is attached to a fibre
channel fabric by means of the N_PORT interface, described in
[FC-FS].
繊維Channel Node--1N_PORTsの収集はFC-2層を超えたレベルによって制御されました。 ノードは[FC-FS]で説明されたN_PORTインタフェースによる繊維チャンネル骨組みに添付されます。
Gateway Region -- The portion of an iFCP fabric accessed through an
iFCP gateway by a remotely attached N_PORT. Fibre channel devices
in the region consist of all those locally attached to the
gateway.
ゲートウェイRegion--iFCPゲートウェイを通してほんの少し付属しているN_PORTによってアクセスされたiFCP骨組みの一部。 その領域の繊維チャンネルデバイスは局所的にゲートウェイに付けられたすべてのものから成ります。
iFCP -- The protocol discussed in this document.
iFCP--本書では議論したプロトコル。
iFCP Frame -- A fibre channel frame encapsulated in accordance with
the FC Frame Encapsulation Specification [ENCAP] and this
specification.
iFCP Frame--繊維チャンネルフレームはFC Frame Encapsulation Specification[ENCAP]とこの仕様通りに要約されました。
iFCP Portal -- An entity representing the point at which a logical or
physical iFCP device is attached to the IP network. The network
address of the iFCP portal consists of the IP address and TCP port
number to which a request is sent when the TCP connection is
created for an iFCP session (see Section 5.2.1).
iFCP Portal--論理的であるか物理的なiFCPデバイスがIPネットワークに取り付けられるポイントを表す実体。 iFCP入り口のネットワーク・アドレスはTCP接続がiFCPセッションのために創造されるとき(セクション5.2.1を見てください)要求が送られるIPアドレスとTCPポートナンバーから成ります。
iFCP Session -- An association comprised of a pair of N_PORTs and a
TCP connection that carries traffic between them. An iFCP session
may be created as the result of a PLOGI fibre channel login
operation.
iFCP Session--協会は1組のNで_PORTsと彼らの間までトラフィックを運ぶTCP接続を包括しました。 iFCPセッションはPLOGI繊維チャンネルログイン操作の結果として作成されるかもしれません。
iSNS -- The server functionality and IP protocol that provide storage
name services in an iFCP network. Fibre channel name services are
implemented by an iSNS name server, as described in [ISNS].
iSNS--ストレージを提供するサーバの機能性とIPプロトコルはiFCPネットワークでサービスを命名します。 繊維チャンネル名前サービスは[ISNS]で説明されるようにiSNSネームサーバによって実装されます。
Locally Attached Device -- With respect to a gateway, a fibre channel
device accessed through the fibre channel fabric to which the
gateway is attached.
局所的にゲートウェイ、繊維チャンネル骨組みを通ってゲートウェイが付けているアクセスされた繊維チャンネルデバイスに関するAttached Device。
Logical iFCP Device -- The abstraction representing a single fibre
channel device as it appears on an iFCP network.
論理的なiFCP Device--それとして単一の繊維チャンネルデバイスを表す抽象化はiFCPネットワークに現れます。
Monia, et al. Standards Track [Page 6] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[6ページ]RFC4172インターネット繊維チャンネル
N_PORT -- An iFCP or fibre channel entity representing the interface
to fibre channel device functionality. This interface implements
the fibre channel N_PORT semantics, specified in [FC-FS]. Fibre
channel defines several variants of this interface that depend on
the fibre channel fabric topology. As used in this document, the
term applies equally to all variants.
N_PORT--繊維チャンネルデバイスの機能性にインタフェースを表すiFCPか繊維チャンネル実体。 このインタフェースは、繊維が[FC-FS]で指定されたチャンネルN_PORT意味論であると実装します。 繊維チャンネルは繊維チャンネル骨組みのトポロジーによるこのインタフェースのいくつかの異形を定義します。 等しく本書では適用という用語をすべての異形に使用するので。
N_PORT Alias -- The N_PORT address assigned by a gateway to
represent a remote N_PORT accessed via the iFCP protocol.
N_PORTアリア--アドレスがPORTがアクセスしたリモートN_を表すためにゲートウェイで割り当てたN_PORTはiFCPを通して議定書を作ります。
N_PORT fabric address -- The address of an N_PORT within the fibre
channel fabric.
N_PORT骨組みのアドレス--繊維チャンネル骨組みの中のN_PORTのアドレス。
N_PORT ID -- The address of a locally attached N_PORT within a
gateway region. N_PORT IDs are assigned in accordance with the
fibre channel rules for address assignment, specified in [FC-FS].
N_PORT ID--ゲートウェイ領域の中の局所的に添付のN_PORTのアドレス。 [FC-FS]で指定されたアドレス課題のための繊維チャンネル規則に従って、N_PORT IDは割り当てられます。
N_PORT Network Address -- The address of an N_PORT in the iFCP
fabric. This address consists of the IP address and TCP port
number of the iFCP Portal and the N_PORT ID of the locally
attached fibre channel device.
N_PORT Network Address--iFCP骨組みのN_PORTのアドレス。 このアドレスはiFCP PortalのIPアドレスとTCPポートナンバーと局所的に添付の繊維チャンネルデバイスのN_PORT IDから成ります。
Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS)
that establishes an iFCP session through the exchange of
identification and operation parameters between an originating
N_PORT and a responding N_PORT.
Login(PLOGI)を移植してください--起因しているN_PORTと応じているN_PORTの間の識別と運転パラメータの交換を通してiFCPセッションを確立する繊維チャンネルExtended Link Service(ELS)。
Remotely Attached Device -- With respect to a gateway, a fibre
channel device accessed from the gateway by means of the iFCP
protocol.
ほんの少しゲートウェイ、iFCPプロトコルによってゲートウェイからアクセスされた繊維チャンネルデバイスに関するAttached Device。
Unbounded iFCP Fabric -- The union of two or more gateway regions
configured to interoperate in address-translation mode.
限りないiFCP Fabric--2つ以上のゲートウェイ領域の組合はアドレス変換モードで共同利用するのを構成されました。
3. Fibre Channel Communication Concepts
3. 繊維チャンネルコミュニケーション概念
Fibre channel is a frame-based, serial technology designed for peer- to-peer communication between devices at gigabit speeds and with low overhead and latency.
繊維チャンネルは、同輩へのデバイスの同輩コミュニケーションのためにギガビット速度において低いオーバーヘッドで設計されたフレームベースの、そして、連続の技術と潜在です。
This section contains a discussion of the fibre channel concepts that form the basis for the iFCP network architecture and protocol described in this document. Readers familiar with this material may skip to Section 4.
このセクションは本書では説明されたiFCPネットワークアーキテクチャとプロトコルの基礎を形成する繊維チャンネル概念の議論を含みます。 この材料に詳しい読者はセクション4までスキップするかもしれません。
Monia, et al. Standards Track [Page 7] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[7ページ]RFC4172インターネット繊維チャンネル
Material presented in this section is drawn from the following T11 specifications:
以下のT11仕様からこのセクションに示された材料を得ます:
-- The Fibre Channel Framing and Signaling Interface, [FC-FS]
-- 繊維チャンネル縁どりとシグナリングは連結します。[FC-FS]
-- Fibre Channel Switch Fabric -2, [FC-SW2]
-- 繊維チャンネルスイッチ骨組み-2[FC-SW2]
-- Fibre Channel Generic Services, [FC-GS3]
-- 繊維チャンネルジェネリックサービス[FC-GS3]
-- Fibre Channel Fabric Loop Attachment, [FC-FLA]
-- 繊維チャンネル骨組みの輪の付属[FC-FLA]
The reader will find an in-depth treatment of the technology in [KEMCMP] and [KEMALP].
読者は[KEMCMP]と[KEMALP]での技術の徹底的な処理を見つけるでしょう。
3.1. The Fibre Channel Network
3.1. 繊維チャンネルネットワーク
The fundamental entity in fibre channel is the fibre channel network. Unlike a layered network architecture, a fibre channel network is largely specified by functional elements and the interfaces between them. As shown in Figure 1, these consist, in part, of the following:
繊維チャンネルによる基本的な実体は繊維チャンネルネットワークです。 階層型ネットワークアーキテクチャと異なって、繊維チャンネルネットワークは機能要素とそれらの間のインタフェースによって主に指定されます。 図1に示されるように、これらは以下から一部成ります:
a) N_PORTs -- The end points for fibre channel traffic. In the FC
standards, N_PORT interfaces have several variants, depending on
the topology of the fabric to which they are attached. As used in
this specification, the term applies to any one of the variants.
a) N_PORTs--終わりは繊維チャンネルトラフィックのために指します。 FC規格では、N_PORTインタフェースがいくつかの異形を持っています、それらが付けている骨組みのトポロジーによって。 この仕様で使用されるように、異形のいずれに適用という用語です。
b) FC Devices -- The fibre channel devices to which the N_PORTs
provide access.
b) FC Devices--N_PORTsがアクセサリーを供給する繊維チャンネルデバイス
c) Fabric Ports -- The interfaces within a fibre channel network that
provide attachment for an N_PORT. The types of fabric port depend
on the fabric topology and are discussed in Section 3.2.
c) 骨組みのPorts--繊維チャンネルネットワークの中のN_PORTに関する付属を提供するインタフェース。 骨組みのポートのタイプについて、骨組みのトポロジーによって、セクション3.2で議論します。
d) The network infrastructure for carrying frame traffic between
N_PORTs.
d) N_PORTsの間までフレームトラフィックを運ぶためのネットワークインフラ。
e) Within a switched or mixed fabric (see Section 3.2), a set of
auxiliary servers, including a name server for device discovery
and network address resolution. The types of service depend on
the network topology.
e) 切り換えられたか複雑な骨組み(セクション3.2を見る)、デバイス発見とネットワークのためのネームサーバを含む1セットの補助のサーバの中では、解決を扱ってください。 サービスのタイプはネットワーク形態を当てにします。
Monia, et al. Standards Track [Page 8] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[8ページ]RFC4172インターネット繊維チャンネル
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device |<-------->| Device | | Device |
|........| |........| |........| |........|
| N_PORT | | N_PORT | | N_PORT | | N_PORT |
+---+----+ +----+---+ +----+---+ +----+---+
| | | |
+---+----+ +----+---+ +----+---+ +----+---+
| Fabric | | Fabric | | Fabric | | Fabric |
| Port | | Port | | Port | | Port |
+========+===+========+==========+========+==+========+
| Fabric |
| & |
| Fabric Services |
+-----------------------------------------------------+
+--------+ +--------+ +--------+ +--------+ | FC| | FC| | FC| | FC| | デバイス| | デバイス| <、-、-、-、-、-、-、--、>| デバイス| | デバイス| |........| |........| |........| |........| | N_ポート| | N_ポート| | N_ポート| | N_ポート| +---+----+ +----+---+ +----+---+ +----+---+ | | | | +---+----+ +----+---+ +----+---+ +----+---+ | 骨組み| | 骨組み| | 骨組み| | 骨組み| | ポート| | ポート| | ポート| | ポート| +========+===+========+==========+========+==+========+ | 骨組み| | & | | 骨組みのサービス| +-----------------------------------------------------+
Figure 1. A Fibre Channel Network
図1。 繊維チャンネルネットワーク
The following sections describe fibre channel network topologies and give an overview of the fibre channel communications model.
以下のセクションは、繊維チャンネルネットワークtopologiesについて説明して、繊維チャンネルコミュニケーションモデルの概要を与えます。
3.2. Fibre Channel Network Topologies
3.2. 繊維チャンネルネットワークTopologies
The principal fibre channel network topologies consist of the following:
主要な繊維チャンネルネットワークtopologiesは以下から成ります:
a) Arbitrated Loop -- A series of N_PORTs connected together in
daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are
referred to as NL_PORTs. Data transmission between NL_PORTs
requires arbitration for control of the loop in a manner similar
to that of a token ring network.
a) 仲裁されたLoop--一連のN_PORTsがデイジーチェインファッションで一緒に接続しました。 [FC-FS]では、輪で接続されたN_PORTsはNL_PORTsと呼ばれます。 NL_PORTsの間のデータ伝送はトークンリングネットワークのものと同様の方法における、輪のコントロールのための仲裁を必要とします。
b) Switched Fabric -- A network consisting of switching elements, as
described in Section 3.2.1.
b) 切り換えられたFabric--セクション3.2.1で説明されるようにスイッチング素子から成るネットワーク。
c) Mixed Fabric -- A network consisting of switches and "fabric-
attached" loops. A description can be found in [FC-FLA]. A
loop-attached N_PORT (NL_PORT) is connected to the loop through an
L_PORT and accesses the fabric by way of an FL_PORT.
c) Mixed Fabric--スイッチと「添付の骨組み」から成るネットワークは輪にされます。 [FC-FLA]で記述を見つけることができます。 輪で付属しているN_PORT(NL_PORT)はL_PORTを通して輪に接続されて、フロリダ_PORTを通して骨組みにアクセスします。
Monia, et al. Standards Track [Page 9] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[9ページ]RFC4172インターネット繊維チャンネル
Depending on the topology, the N_PORT and its means of network attachment may be one of the following:
トポロジー、N_PORT、およびそのネットワーク付属の手段によるのは、以下の1つであるかもしれません:
FC Network
Topology Network Interface N_PORT Variant
--------------- ----------------- --------------
Loop L_PORT NL_PORT
FCネットワーク形態ネットワーク・インターフェースN_ポート異形--------------- ----------------- -------------- 輪のL_ポートNL_ポート
Switched F_PORT N_PORT
切り換えられたF_ポートN_ポート
Mixed FL_PORT via L_PORT NL_PORT
_L PORT NL_PORTを通したMixedフロリダ_PORT
F_PORT N_PORT
F_ポートN_ポート
The differences in each N_PORT variant and its corresponding fabric port are confined to the interactions between them. To an external N_PORT, all fabric ports are transparent, and all remote N_PORTs are functionally identical.
それぞれのN_PORT異形とその対応する骨組みのポートの違いはそれらの間の相互作用に閉じ込められます。 外部のN_PORTに、すべての骨組みのポートが透明です、そして、すべてのリモートN_PORTsが機能上同じです。
Monia, et al. Standards Track [Page 10] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[10ページ]RFC4172インターネット繊維チャンネル
3.2.1. Switched Fibre Channel Fabrics
3.2.1. 切り換えられた繊維チャンネル骨組み
An example of a multi-switch fibre channel fabric is shown in Figure 2.
マルチスイッチ繊維チャンネル骨組みに関する例は図2に示されます。
+----------+ +----------+
| FC | | FC |
| Device | | Device |
|..........| |..........|
| N_PORT |<........>| N_PORT |
+----+-----+ +-----+----+
| |
+----+-----+ +-----+----+
| F_PORT | | F_PORT |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+ Fibre Channel
|Inter- | |Inter- | Fabric
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
+----------+ +----------+ | FC| | FC| | デバイス| | デバイス| |..........| |..........| | N_ポート|<…>| N_ポート| +----+-----+ +-----+----+ | | +----+-----+ +-----+----+ | F_ポート| | F_ポート| ==========+==========+==========+==========+============== | FC| | FC| | スイッチ| | スイッチ| +----------+ +----------+ 繊維チャンネル|相互| |相互| 骨組み|スイッチ| |スイッチ| |インタフェース| |インタフェース| +-----+----+ +-----+----+ | | | | +-----+----+----------+-----+----+ |相互| |相互| |スイッチ| |スイッチ| |インタフェース| |インタフェース| +----------+ +----------+ | FCスイッチ| | | +--------------------------------+
Figure 2. Multi-Switch Fibre Channel Fabric
図2。 マルチスイッチ繊維チャンネル骨組み
The interface between switch elements is either a proprietary interface or the standards-compliant E_PORT interface, which is described by the FC-SW2 specification, [FC-SW2].
スイッチ素子の間のインタフェースは、独占インタフェースか規格対応することのE_PORTインタフェースのどちらかです。(FC-SW2仕様[FC-SW2]でそのインタフェースは説明されます)。
Monia, et al. Standards Track [Page 11] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[11ページ]RFC4172インターネット繊維チャンネル
3.2.2. Mixed Fibre Channel Fabric
3.2.2. Mixed繊維チャンネル骨組み
A mixed fabric contains one or more arbitrated loops connected to a switched fabric as shown in Figure 3.
複雑な骨組みは1か図3に示されるように切り換えられた骨組みに接続されたさらに仲裁された輪を含んでいます。
+----------+ +----------+ +---------+
| FC | | FC | | FC |
| Device | | Device | | Device |
|..........| FC |..........| |.........|
| N_PORT |<........>| NL_PORT +---+ NL_PORT |
+----+-----+ Traffic +-----+----+ +----+----+
| | FC Loop |
+----+-----+ +-----+----+ |
| F_PORT | | FL_PORT +--------+
| | | |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
+----------+ +----------+ +---------+ | FC| | FC| | FC| | デバイス| | デバイス| | デバイス| |..........| FC|..........| |.........| | N_ポート|<…>| NL_ポート+---+ NL_ポート| +----+-----+ トラフィック+-----+----+ +----+----+ | | FC輪| +----+-----+ +-----+----+ | | F_ポート| | フロリダ_ポート+--------+ | | | | ==========+==========+==========+==========+============== | FC| | FC| | スイッチ| | スイッチ| +----------+ +----------+ |相互| |相互| |スイッチ| |スイッチ| |インタフェース| |インタフェース| +-----+----+ +-----+----+ | | | | +-----+----+----------+-----+----+ |相互| |相互| |スイッチ| |スイッチ| |インタフェース| |インタフェース| +----------+ +----------+ | FCスイッチ| | | +--------------------------------+
Figure 3. Mixed Fibre Channel Fabric
図3。 Mixed繊維チャンネル骨組み
As noted previously, the protocol for communications between peer N_PORTs is independent of the fabric topology, N_PORT variant, and type of fabric port to which an N_PORT is attached.
以前に注意されるように、同輩N_PORTsのコミュニケーションのためのプロトコルはN_PORTが付けている骨組みのトポロジー、N_PORT異形、および骨組みのポートのタイプから独立しています。
3.3. Fibre Channel Layers and Link Services
3.3. 繊維チャンネル層とリンクサービス
A fibre channel consists of the following layers:
繊維チャンネルは以下の層から成ります:
FC-0 -- The interface to the physical media.
FC-0--物理的なメディアへのインタフェース。
FC-1 -- The encoding and decoding of data and out-of-band physical
link control information for transmission over the physical media.
FC-1--データとバンドで出ている物理的なリンクのコード化と解読は物理的なメディアの上のトランスミッションのための情報を制御します。
Monia, et al. Standards Track [Page 12] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[12ページ]RFC4172インターネット繊維チャンネル
FC-2 -- The transfer of frames, sequences, and Exchanges
comprising protocol information units.
FC-2--フレームの転送、系列、およびExchanges包括は情報ユニットについて議定書の中で述べます。
FC-3 -- Common Services.
FC-3--共益サービス。
FC-4 -- Application protocols such as the fibre channel protocol
for SCSI (FCP).
FC-4--繊維チャンネルなどのアプリケーション・プロトコルはSCSI(FCP)のために議定書を作ります。
In addition to the layers defined above, a fibre channel defines a set of auxiliary operations, some of which are implemented within the transport layer fabric, called link services. These are required in order to manage the fibre channel environment, establish communications with other devices, retrieve error information, perform error recovery, and provide other similar services. Some link services are executed by the N_PORT. Others are implemented internally within the fabric. These internal services are described in the next section.
上で定義された層に加えて、繊維チャンネルは1セットの補助の操作を定義します。その或るものはトランスポート層骨組み(呼ばれたリンクサービス)の中で実装されます。 これらが、繊維流通経路環境を管理して、対向機器とのコミュニケーションを確立して、エラー情報を検索して、エラー回復を実行して、他の同様のサービスを提供するのに必要です。 いくつかのリンクサービスがN_PORTによって実行されます。 他のものは骨組みの中で内部的に実装されます。 これらの内部のサービスは次のセクションで説明されます。
3.3.1. Fabric-Supplied Link Services
3.3.1. 骨組みに供給されたリンクサービス
Servers that are internal to a switched fabric handle certain classes of Link Service requests and service-specific commands. The servers appear as N_PORTs located at the 'well-known' N_PORT fabric addresses specified in [FC-FS]. Service requests use the standard fibre channel mechanisms for N_PORT-to-N_PORT communications.
切り換えられた骨組みに内部であることのサーバはあるクラスのLink Service要求とサービス特有のコマンドを扱います。 N_PORTsが[FC-FS]で指定されたN'よく知られる'_PORT骨組みのアドレスで場所を見つけたので、サーバは現れます。 サービスのリクエストはN_PORTからN_PORTコミュニケーションに標準の繊維チャンネルメカニズムを使用します。
All switched fabrics must provide the following services:
すべての切り換えられた骨組みが以下のサービスを提供しなければなりません:
Fabric F_PORT server -- Services N_PORT requests to access the
fabric for communications.
骨組みのF_PORTサーバ--コミュニケーションのために骨組みにアクセスするというサービスN_PORT要求。
Fabric Controller -- Provides state change information to inform
other FC devices when an N_PORT exits or enters the fabric (see
Section 3.5).
骨組みのController--N_PORTがいつ出るか、または骨組みに入るかを(セクション3.5を見てください)他のFCデバイスに知らせるために州の変化情報を提供します。
Directory/Name Server - Allows N_PORTs to register information in
a database, retrieve information about other N_PORTs, and to
discover other devices as described in Section 3.5.
ディレクトリ/名前Server--N_PORTsがデータベースの情報を登録するのを許容して、他のN_PORTsの情報を検索する、セクション3.5で説明されるように対向機器を発見します。
A switched fabric may also implement the following optional services:
また、切り換えられた骨組みは、↓これが任意のサービスであると実装するかもしれません:
Broadcast Address/Server -- Transmits single-frame, class 3
sequences to all N_PORTs.
放送Address/サーバ--シングルフレーム、クラス3系列をすべてのN_PORTsに伝えます。
Time Server -- Intended for the management of fabric-wide
expiration timers or elapsed time values; not intended for precise
time synchronization.
時間Server--骨組みの全体の満了の管理のために、タイマか経過時間値を意図します。 正確な時間同期化のために、意図していません。
Monia, et al. Standards Track [Page 13] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[13ページ]RFC4172インターネット繊維チャンネル
Management Server - Collects and reports management information,
such as link usage, error statistics, link quality, and similar
items.
管理Server--集まって、リンク用法などの経営情報、誤り統計が上質の、そして、同様の項目をリンクすると報告します。
Quality of Service Facilitator - Performs fabric-wide bandwidth
and latency management.
Service Facilitatorの品質--骨組みの全体の帯域幅と潜在管理を実行します。
3.4. Fibre Channel Nodes
3.4. 繊維チャンネルノード
A fibre channel node has one or more fabric-attached N_PORTs. The node and its N_PORTs have the following associated identifiers:
繊維チャンネルノードには、1骨組みで付属しているN_PORTsがあります。 ノードとそのN_PORTsには、以下の関連識別子があります:
a) A worldwide-unique identifier for the node.
a) ノードのための世界的なユニークな識別子。
b) A worldwide-unique identifier for each N_PORT associated with the
node.
b) ノードに関連しているそれぞれのN_PORTに、世界的なユニークな識別子。
c) For each N_PORT attached to a fabric, a 24-bit fabric-unique
address with the properties defined in Section 3.7.1. The fabric
address is the address to which frames are sent.
c) それぞれのN_に関しては、PORTは骨組み、特性がセクション3.7.1で定義されている24ビットの骨組みのユニークなアドレスに付きました。 骨組みのアドレスはフレームが送られるアドレスです。
Each worldwide-unique identifier is a 64-bit binary quantity with the format defined in [FC-FS].
それぞれの世界的なユニークな識別子は書式が[FC-FS]で定義されている64ビットの2進の量です。
3.5. Fibre Channel Device Discovery
3.5. 繊維チャンネルデバイス発見
In a switched or mixed fabric, fibre channel devices and changes in the device configuration may be discovered by means of services provided by the fibre channel Name Server and Fabric Controller.
切り換えられたか複雑な骨組みでは、デバイス構成における繊維チャンネルデバイスと変化は繊維のチャンネルName ServerとFabric Controllerによって提供されたサービスによって発見されるかもしれません。
The Name Server provides registration and query services that allow a fibre channel device to register its presence on the fabric and to discover the existence of other devices. For example, one type of query obtains the fabric address of an N_PORT from its 64-bit worldwide-unique name. The full set of supported fibre channel name server queries is specified in [FC-GS3].
Name Serverは繊維チャンネルデバイスが骨組みの上に存在を示して、対向機器の存在を発見する登録と質問サービスを、提供します。 例えば、1つのタイプの質問は64ビットの世界的なユニークな名前からN_PORTの骨組みのアドレスを得ます。 サポートしている繊維チャンネルネームサーバ質問のフルセットは[FC-GS3]で指定されます。
The Fabric Controller complements the static discovery capabilities provided by the Name Server through a service that dynamically alerts a fibre channel device whenever an N_PORT is added or removed from the configuration. A fibre channel device receives these notifications by subscribing to the service as specified in [FC-FS].
Fabric ControllerはN_PORTが構成から加えられるか、または取り外されるときはいつも、ダイナミックに繊維チャンネルデバイスを警告するサービスでName Serverによって提供された静的な発見能力の補足となります。 繊維チャンネルデバイスは、[FC-FS]で指定されているとしてサービスに加入することによって、これらの通知を受け取ります。
Monia, et al. Standards Track [Page 14] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[14ページ]RFC4172インターネット繊維チャンネル
3.6. Fibre Channel Information Elements
3.6. 繊維経路情報要素
The fundamental element of information in fibre channel is the frame. A frame consists of a fixed header and up to 2112 bytes of payload with the structure described in Section 3.7. The maximum frame size that may be transmitted between a pair of fibre channel devices is negotiable up to the payload limit, based on the size of the frame buffers in each fibre channel device and the path maximum transmission unit (MTU) supported by the fabric.
繊維チャンネルによる情報の基本的な要素はフレームです。 フレームは構造がセクション3.7で説明されている固定ヘッダーと最大2112バイトのペイロードから成ります。 1組の繊維チャンネルデバイスの間に伝えられるかもしれない最大のフレーム・サイズは骨組みによって支えられたそれぞれの繊維チャンネルデバイスと経路マキシマム・トランスミッション・ユニット(MTU)のフレームバッファのサイズに基づいてペイロード限界まで交渉可能です。
Operations involving the transfer of information between N_PORT pairs are performed through 'Exchanges'. In an Exchange, information is transferred in one or more ordered series of frames, referred to as Sequences.
N_PORT組の間の情報の転送にかかわる操作が'交換'を通して実行されます。 Exchangeでは、Sequencesと呼ばれた1つ以上の規則正しいシリーズのフレームで情報を移します。
Within this framework, an upper layer protocol is defined in terms of transactions carried by Exchanges. In turn, each transaction consists of protocol information units, each of which is carried by an individual Sequence within an Exchange.
このフレームワークの中では、上側の層のプロトコルはExchangesによって運ばれたトランザクションで定義されます。 順番に、各トランザクションはプロトコル情報ユニットから成ります。それはExchangeの中で個々のSequenceによってそれぞれ運ばれます。
3.7. Fibre Channel Frame Format
3.7. 繊維チャンネルフレーム形式
A fibre channel frame consists of a header, payload and 32-bit CRC bracketed by SOF and EOF delimiters. The header contains the control information necessary to route frames between N_PORTs and manage Exchanges and Sequences. The following diagram gives a schematic view of the frame.
繊維チャンネルフレームはヘッダー、ペイロード、およびSOFとEOFデリミタによって腕木を付けられた32ビットのCRCから成ります。 ヘッダーはN_PORTsの間にフレームを発送して、ExchangesとSequencesを管理するのに必要な制御情報を含んでいます。 以下のダイヤグラムはフレームの図式の意見を与えます。
Monia, et al. Standards Track [Page 15] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[15ページ]RFC4172インターネット繊維チャンネル
Bit 0 31
+-----------------------------+
Word 0 | Start-of-frame Delimiter |
+-----+-----------------------+<----+
| | Destination N_PORT | |
1 | | Fabric Address (D_ID) | |
| | (24 bits) | |
+-----+-----------------------+ 24-byte
| | Source N_PORT | Frame
2 | | Fabric Address (S_ID) | Header
| | (24 bits) | |
+-----+-----------------------+ |
3 | Control information for | |
. | frame type, Exchange | |
. | management, IU | |
. | segmentation and | |
6 | re-assembly | |
+-----------------------------+<----+
7 | |
. | Frame payload |
. | (0 - 2112 bytes) |
. | |
. | |
. | |
+-----------------------------+
. | CRC |
+-----------------------------+
n | End-of-Frame Delimiter |
+-----------------------------+
ビット0 31+-----------------------------+ Word0| フレームのスタートデリミタ| +-----+-----------------------+ <。----+ | | 目的地N_港| | 1 | | 骨組みのアドレス(D_ID)| | | | (24ビット) | | +-----+-----------------------+ 24バイト| | ソースN_港| フレーム2| | 骨組みのアドレス(S_ID)| ヘッダー| | (24ビット) | | +-----+-----------------------+ | 3 | 情報を制御します。| | . | フレームタイプ、Exchange| | . | 管理、IU| | . | そして分割。| | 6 | 再アセンブリ| | +-----------------------------+ <。----+ 7 | | . | フレームペイロード| . | (0--2112バイト) | . | | . | | . | | +-----------------------------+ . | CRC| +-----------------------------+ n| フレームの端のデリミタ| +-----------------------------+
Figure 4. Fibre Channel Frame Format
図4。 繊維チャンネルフレーム形式
The source and destination N_PORT fabric addresses embedded in the S_ID and D_ID fields represent the physical addresses of originating and receiving N_PORTs, respectively.
N_PORT骨組みのアドレスがS_IDとD_ID分野に埋め込んだ情報筋と目的地はそれぞれN_PORTsを溯源して、受ける物理アドレスを表します。
3.7.1. N_PORT Address Model
3.7.1. N_ポートアドレスモデル
N_PORT fabric addresses are 24-bit values with the following format, defined by the fibre channel specification [FC-FS]:
N_PORT骨組みのアドレスが繊維チャンネル仕様[FC-FS]で定義された以下の書式がある24ビットの値です:
Bit 0 7 8 15 16 23
+-----------+------------+----------+
| Domain ID | Area ID | Port ID |
+-----------+------------+----------+
ビット0 7 8 15 16 23、+-----------+------------+----------+ | ドメインID| 領域ID| IDを移植してください。| +-----------+------------+----------+
Figure 5. Fibre Channel Address Format
図5。 繊維チャンネル・アドレス形式
Monia, et al. Standards Track [Page 16] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[16ページ]RFC4172インターネット繊維チャンネル
A fibre channel device acquires an address when it logs into the fabric. Such addresses are volatile and subject to change based on modifications in the fabric configuration.
骨組みにログインするとき、繊維チャンネルデバイスはアドレスを習得します。 そのようなアドレスは、揮発性であり、骨組みの構成における変更に基づいて変更される可能性があります。
In a fibre channel fabric, each switch element has a unique Domain ID assigned by the principal switch. The value of the Domain ID ranges from 1 to 239 (0xEF). Each switch element, in turn, administers a block of addresses divided into area and port IDs. An N_PORT connected to an F_PORT receives a unique fabric address, consisting of the switch's Domain ID concatenated with switch-assigned area and port IDs.
繊維チャンネル骨組みでは、各スイッチ素子で、主要なスイッチはユニークなDomain IDを割り当てます。 Domain IDの値は1〜239まで及びます(0xEF)。 各スイッチ素子は順番に1ブロックの領域に分割されたアドレスとポートIDを管理します。 F_PORTに接続されたN_PORTはユニークな骨組みのアドレスを受け取ります、スイッチで割り当てられた領域で連結されたスイッチのDomain IDとポートIDから成って。
A loop-attached NL_PORT (see Figure 3) obtains the Port ID component of its address during the loop initialization process described in [FC-AL2]. The area and domain IDs are supplied by the fabric when the fabric login (FLOGI) is executed.
輪で付属しているNL_PORT(図3を見る)は[FC-AL2]で説明された輪の初期化プロセスの間、アドレスのPort IDの部品を得ます。 骨組みのログイン(FLOGI)を実行するとき、骨組みから領域とドメインIDを供給します。
3.8. Fibre Channel Transport Services
3.8. 繊維チャンネル輸送サービス
N_PORTs communicate by means of the following classes of service, which are specified in the fibre channel standard ([FC-FS]):
N_PORTsは以下のサービスのクラスによって交信します:クラスは繊維チャンネル規格([FC-FS])で指定されます。
Class 1 - A dedicated physical circuit connecting two N_PORTs.
クラス1--2N_PORTsを接続する専用実回線。
Class 2 - A frame-multiplexed connection with end-to-end flow
control and delivery confirmation.
クラス2--終わりから終わりへのフロー制御と配送確認とのフレームで多重送信された関係。
Class 3 - A frame-multiplexed connection with no provisions for
end-to-end flow control or delivery confirmation.
クラス3--終わりから終わりへのフロー制御か配送確認のための条項のないフレームで多重送信された接続。
Class 4 -- A connection-oriented service, based on a virtual
circuit model, providing confirmed delivery with bandwidth and
latency guarantees.
クラス4--コネクション型サービスであり、事実上の回路モデルに基づいて提供は帯域幅に伴う配送と潜在保証を確認しました。
Class 6 -- A reliable multicast service derived from class 1.
クラス6--信頼できるマルチキャストサービスがクラス1に由来していました。
Classes 2 and 3 are the predominant services supported by deployed fibre channel storage and clustering systems.
クラス2と3は繊維河道貯留であると配布されて、システムをクラスタリングさせることによってサポートされた支配的なサービスです。
Class 3 service is similar to UDP or IP datagram service. Fibre channel storage devices using this class of service rely on the ULP implementation to detect and recover from transient device and transport errors.
クラス3サービスはUDPかIPデータグラムサービスと同様です。 このクラスのサービスを利用する繊維チャンネル記憶装置が一時的なデバイスと輸送誤りから検出して、克服するULP実装を当てにします。
For class 2 and class 3 service, the fibre channel fabric is not required to provide in-order delivery of frames unless it is explicitly requested by the frame originator (and supported by the fabric). If ordered delivery is not in effect, it is the
クラス2と3がサービスを提供するクラスにおいて、それがフレーム創始者(そして、骨組みで、サポートされる)によって明らかに要求されない場合、繊維チャンネル骨組みはオーダーにおける、フレームの配送を提供する必要はありません。 命令された配送が有効でないなら、それは有効です。
Monia, et al. Standards Track [Page 17] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[17ページ]RFC4172インターネット繊維チャンネル
responsibility of the frame recipient to reconstruct the order in which frames were sent, based on information in the frame header.
フレーム受取人がどのフレームでオーダーを再建するか責任を送りました、フレームヘッダーの情報に基づいて。
3.9. Login Processes
3.9. ログインプロセス
The Login processes are FC-2 operations that allow an N_PORT to establish the operating environment necessary to communicate with the fabric, other N_PORTs, and ULP implementations accessed via the N_PORT. Three login operations are supported:
LoginプロセスはN_PORTが実装がN_PORTを通してアクセスした骨組み、他のN_PORTs、およびULPとコミュニケートするのに必要な操作環境を確立できるFC-2操作です。 3つのログイン操作がサポートされます:
a) Fabric Login (FLOGI) -- An operation whereby the N_PORT registers
its presence on the fabric, obtains fabric parameters, such as
classes of service supported, and receives its N_PORT address,
a) 骨組みのログイン(FLOGI) -- N_PORTが骨組みの上に存在を示して、サポートされたサービスのクラスなどの骨組みのパラメタを得て、N_PORTアドレスを受け取る操作
b) Port Login (PLOGI) -- An operation by which an N_PORT establishes
communication with another N_PORT.
b) ポートログイン(PLOGI) -- N_PORTが別のN_PORTとのコミュニケーションを確立する操作。
c) Process Login (PRLOGI) -- An operation that establishes the
process-to-process communications associated with a specific FC-4
ULP, such as FCP-2, the fibre channel SCSI mapping.
c) プロセスログイン(PRLOGI) -- プロセス間通信を確立する操作は特定のFC-4 ULPと交際しました、FCP-2などのように、繊維チャンネルSCSIマッピング。
Since N_PORT addresses are volatile, an N_PORT originating a login (PLOGI) operation executes a Name Server query to discover the fibre channel address of the remote device. A common query type involves use of the worldwide-unique name of an N_PORT to obtain the 24-bit N_PORT fibre channel address to which the PLOGI request is sent.
N_PORTアドレスが不安定であるので、ログイン(PLOGI)操作を溯源するN_PORTは遠隔装置の繊維チャンネル・アドレスを発見するためにName Server質問を実行します。 一般的な質問タイプは、PLOGI要求が送られる24ビットのN_PORT繊維チャンネル・アドレスを得るためにN_PORTという世界的なユニークな名前の使用を伴います。
4. The iFCP Network Model
4. iFCPネットワークモデル
The iFCP protocol enables the implementation of fibre channel fabric functionality on an IP network in which IP components and technology replace the fibre channel switching and routing infrastructure described in Section 3.2.
iFCPプロトコルはIPコンポーネントと技術がセクション3.2で説明された繊維チャンネルの切り換えとルーティングインフラストラクチャを置き換えるIPネットワークに関する繊維チャンネル骨組みの機能性の実装を可能にします。
The example of Figure 6 shows a fibre channel network with attached devices. Each device accesses the network through an N_PORT connected to an interface whose behavior is specified in [FC-FS] or [FC-AL2]. In this case, the N_PORT represents any of the variants described in Section 3.2. The interface to the fabric may be an L_PORT, F_PORT, or FL_PORT.
図6に関する例は付属デバイスで繊維チャンネルネットワークを示しています。 各デバイスは振舞いが[FC-FS]か[FC-AL2]で指定されるインタフェースに接続されたN_PORTを通してネットワークにアクセスします。 この場合、N_PORTはセクション3.2で説明された異形のいずれも表します。 骨組みへのインタフェースは、L_PORT、F_PORT、またはフロリダ_PORTであるかもしれません。
Within the fibre channel device domain, addressable entities consist of other N_PORTs and fibre channel devices internal to the network that perform the fabric services defined in [FC-GS3].
繊維チャンネルデバイスドメインの中では、アドレス可能な実体は[FC-GS3]で定義された骨組みのサービスを実行するネットワークへの内部の他のN_PORTsと繊維チャンネルデバイスから成ります。
Monia, et al. Standards Track [Page 18] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[18ページ]RFC4172インターネット繊維チャンネル
Fibre Channel Network
+--------+ +--------+
| FC | | FC |
| Device | | Device |
|........| FC |........| Fibre Channel
| N_PORT |<......>| N_PORT | Device Domain
+---+----+ Traffic+----+---+ ^
| | |
+---+----+ +----+---+ |
| Fabric | | Fabric | |
| Port | | Port | |
==========+========+========+========+==============
| FC Network & | |
| Fabric Services | v
| | Fibre Channel
+--------------------------+ Network Domain
繊維チャンネルネットワーク+--------+ +--------+ | FC| | FC| | デバイス| | デバイス| |........| FC|........| 繊維チャンネル| N_ポート|<…>| N_ポート| デバイスドメイン+---+----+ トラフィック+----+---+ ^ | | | +---+----+ +----+---+ | | 骨組み| | 骨組み| | | ポート| | ポート| | ==========+========+========+========+============== | FCはネットワークでつなぎます。| | | 骨組みのサービス| v| | 繊維チャンネル+--------------------------+ ネットワークドメイン
Figure 6. A Fibre Channel Network
図6。 繊維チャンネルネットワーク
Gateway Region Gateway Region
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device | | Device | | Device | Fibre
|........| |........| FC |........| |........| Channel
| N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device
+---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain
| | | | ^
+---+----+ +---+----+ +----+---+ +----+---+ |
| F_PORT | | F_PORT | | F_PORT | | F_PORT | |
=+========+==+========+===========+========+==+========+==========
| iFCP Layer |<--------->| iFCP Layer | |
|....................| ^ |....................| |
| iFCP Portal | | | iFCP Portal | v
+--------+-----------+ | +----------+---------+ IP
iFCP|Gateway Control iFCP|Gateway Network
| Data |
| |
| |
|<------Encapsulated Frames------->|
| +------------------+ |
| | | |
+------+ IP Network +--------+
| |
+------------------+
ゲートウェイ領域のゲートウェイ地域+--------+ +--------+ +--------+ +--------+ | FC| | FC| | FC| | FC| | デバイス| | デバイス| | デバイス| | デバイス| 繊維|........| |........| FC|........| |........| チャンネル| N_ポート| | N_ポート|<…>| N_ポート| | N_ポート| デバイス+---+----+ +---+----+ トラフィック+----+---+ +----+---+ ドメイン| | | | ^ +---+----+ +---+----+ +----+---+ +----+---+ | | F_ポート| | F_ポート| | F_ポート| | F_ポート| | =+========+==+========+===========+========+==+========+========== | iFCP層| <、-、-、-、-、-、-、-、--、>| iFCP層| | |....................| ^ |....................| | | iFCP入り口| | | iFCP入り口| +に対して--------+-----------+ | +----------+---------+ IP iFCP|ゲートウェイコントロールiFCP|ゲートウェイネットワーク| データ| | | | | | <、-、-、-、-、--フレームであるとカプセル化されます。------->|、| +------------------+ | | | | | +------+ IPネットワーク+--------+ | | +------------------+
Figure 7. An iFCP Fabric Example
図7。 iFCP骨組みの例
Monia, et al. Standards Track [Page 19] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[19ページ]RFC4172インターネット繊維チャンネル
One example of an equivalent iFCP fabric is shown in Figure 7. The fabric consists of two gateway regions, each accessed by a single iFCP gateway.
同等なiFCP骨組みに関する1つの例が図7に示されます。 骨組みは1iFCP門によってそれぞれアクセスされた2つのゲートウェイ領域から成ります。
Each gateway contains two standards-compliant F_PORTs and an iFCP Portal for attachment to the IP network. Fibre channel devices in the region are those locally connected to the iFCP fabric through the gateway fabric ports.
各ゲートウェイは2規格対応することのF_PORTsとIPネットワークへの付属のためのiFCP Portalを含んでいます。 その領域の繊維チャンネルデバイスはゲートウェイ骨組みのポートを通して局所的にiFCP骨組みに関連づけられたものです。
Looking into the fabric port, the gateway appears as a fibre channel switch element. At this interface, remote N_PORTs are presented as fabric-attached devices. Conversely, on the IP network side, the gateway presents each locally connected N_PORT as a logical fibre channel device.
骨組みのポートを調べて、ゲートウェイは繊維チャンネルスイッチ素子として現れます。 このインタフェースでは、骨組みで付属しているデバイスとしてリモートN_PORTsを寄贈します。 逆に、IPネットワーク側では、ゲートウェイが論理的な繊維チャンネルデバイスとしてそれぞれの局所的に接続されたN_PORTを示します。
Extrapolating to the general case, each gateway region behaves like an autonomous system whose configuration is invisible to the IP network and other gateway regions. Consequently, in addition to the F_PORT shown in the example, a gateway implementation may transparently support the following fibre channel interfaces:
一般的なケースに推定して、それぞれのゲートウェイ領域は構成がIPネットワークと他のゲートウェイ領域に目に見えない自律システムのように振る舞います。 その結果、例で見せられたF_PORTに加えて、ゲートウェイ実装は、以下の繊維がチャンネル・インタフェースであると透過的にサポートするかもしれません:
Inter-Switch Link -- A fibre channel switch-to-switch interface
used to access a region containing fibre channel switch elements.
An implementation may support the E_PORT defined by [FC-SW2] or
one of the proprietary interfaces provided by various fibre
channel switch vendors. In this case, the gateway acts as a
border switch connecting the gateway region to the IP network.
相互Switch Link--繊維チャンネルスイッチからスイッチへのインタフェースは以前はよく繊維チャンネルスイッチ素子を含む領域にアクセスしていました。 実装はPORTが[FC-SW2]で定義したE_か様々な繊維チャンネルスイッチベンダーによって提供された独占インタフェースの1つをサポートするかもしれません。 この場合、ゲートウェイはIPネットワークにゲートウェイ領域をつなげる境界スイッチとして作動します。
FL_PORT -- An interface that provides fabric access for loop-
attached fibre channel devices, as specified in [FC-FLA].
フロリダ_PORT--輪のための骨組みのアクセスを提供するインタフェースは[FC-FLA]で指定されるように繊維チャンネルデバイスを取り付けました。
L_PORT -- An interface through which a gateway may emulate the
fibre channel loop environment specified in [FC-AL2]. As
discussed in appendix B, the gateway presents remotely accessed
N_PORTS as loop-attached devices.
L_PORT--ゲートウェイが繊維チャンネル輪の環境を見習うかもしれないインタフェースは[FC-AL2]で指定しました。 付録Bで議論するように、ゲートウェイは輪で付属しているデバイスとして離れてアクセスされたN_PORTSを寄贈します。
The manner in which these interfaces are provided by a gateway is implementation specific and therefore beyond the scope of this document.
実装特有であり、したがって、このドキュメントの範囲を超えてこれらのインタフェースがゲートウェイによって提供される方法。
Although each region is connected to the IP network through one gateway, a region may incorporate multiple gateways for added performance and fault tolerance if the following conditions are met:
各領域は1門を通してIPネットワークにつなげられますが、以下の条件が満たされるなら、領域は加えられた性能と耐障害性のために複数のゲートウェイを組み込むかもしれません:
a) The gateways MUST coordinate the assignment of N_PORT IDs and
aliases so that each N_PORT has one and only one address.
a) ゲートウェイがN_PORT IDと別名の課題を調整しなければならないので、各N_PORTには、唯一無二の1つのアドレスがあります。
Monia, et al. Standards Track [Page 20] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[20ページ]RFC4172インターネット繊維チャンネル
b) All iFCP traffic between a given remote and local N_PORT pair MUST
flow through the same iFCP session (see Section 5.2.1). However,
iFCP sessions to a given remotely attached N_PORT need not
traverse the same gateway.
b) N与えられたリモートで地元の_PORT組の間のすべてのiFCPトラフィックが同じiFCPセッションで流れなければなりません(セクション5.2.1を見てください)。 しかしながら、PORTが必要とする与えられたほんの少し付属しているN_へのiFCPセッションは同じゲートウェイを横断しません。
Coordinating address assignments and managing the flow of traffic is implementation specific and outside the scope of this specification.
実装特有であり、この仕様の範囲の外でアドレス課題を調整して、トラフィックの流れを管理する。
4.1. iFCP Transport Services
4.1. iFCP輸送サービス
N_PORT to N_PORT communications that traverse a TCP/IP network require the intervention of the iFCP layer within the gateway. This consists of the following operations:
TCP/IPネットワークを横断するN_PORTコミュニケーションへのN_PORTはゲートウェイの中でiFCP層の介入を必要とします。 これは以下の操作から成ります:
a) Execution of the frame-addressing and -mapping functions described
in Section 4.4.
a) セクション4.4で説明されたフレームアドレシングとマッピング機能の実行。
b) Encapsulation of fibre channel frames for injection into the
TCP/IP network and de-encapsulation of fibre channel frames
received from the TCP/IP network.
b) TCP/IPネットワークへの注射のための繊維チャンネルフレームのカプセル化と繊維チャンネルフレームの反-カプセル化はTCP/IPネットワークから受信されました。
c) Establishment of an iFCP session in response to a PLOGI directed
to a remote device.
c) 遠隔装置に向けられたPLOGIに対応したiFCPセッションの設立。
Section 4.4 discusses the iFCP frame-addressing mechanism and the way that it is used to achieve communications transparency between N_PORTs.
セクション4.4はフレームを扱うiFCPメカニズムとそれがN_PORTsの間のコミュニケーション透明を達成するのに使用される方法を論じます。
4.1.1. Fibre Channel Transport Services Supported by iFCP
4.1.1. iFCPによってサポートされた繊維チャンネル輸送サービス
An iFCP fabric supports Class 2 and Class 3 fibre channel transport services, as specified in [FC-FS]. An iFCP fabric does not support Class 4, Class 6, or Class 1 (dedicated connection) service. An N_PORT discovers the classes of transport services supported by the fabric during fabric login.
iFCP骨組みは、[FC-FS]で指定されるようにClass2とClass3が繊維チャンネル輸送サービスであるとサポートします。 iFCP骨組みはClass4、Class6、またはClass1(接続を捧げます)にサービスをサポートしません。 N_PORTは、骨組みの間に骨組みで後押しされている輸送サービスのクラスがログインすると発見します。
4.2. iFCP Device Discovery and Configuration Management
4.2. iFCPデバイス発見と構成管理
An iFCP implementation performs device discovery and iFCP fabric management through the Internet Storage Name Service defined in [ISNS]. Access to an iSNS server is required to perform the following functions:
iFCP実装は[ISNS]で定義されたインターネットStorage Name Serviceを通したデバイス発見とiFCP骨組みの管理を実行します。 iSNSサーバへのアクセスが以下の機能を実行するのに必要です:
a) Emulate the services provided by the fibre channel name server
described in Section 3.3.1, including a mechanism for
asynchronously notifying an N_PORT of changes in the iFCP fabric
configuration.
a) セクション3.3.1で説明された繊維チャンネルネームサーバによって提供されたサービスを見習ってください、iFCP骨組みの構成における変化についてN_PORTに非同期に通知するためのメカニズムを含んでいて。
Monia, et al. Standards Track [Page 21] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[21ページ]RFC4172インターネット繊維チャンネル
b) Aggregate gateways into iFCP fabrics for interoperation.
b) interoperationのためにiFCP骨組みへのゲートウェイに集めてください。
c) Segment an iFCP fabric into fibre channel zones through the
definition and management of device discovery scopes, referred to
as 'discovery domains'.
c) '発見ドメイン'と呼ばれて、デバイス発見の定義と管理による繊維チャンネルゾーンへのiFCP骨組みが見るセグメント。
d) Store and distribute security policies, as described in Section
10.2.9.
d) セクション10.2.9で説明されるように安全保障政策を保存して、分配してください。
e) Implementation of the fibre channel broadcast mechanism.
e) 繊維チャンネルの実装はメカニズムを放送しました。
4.3. iFCP Fabric Properties
4.3. iFCP骨組みの特性
A collection of iFCP gateways may be configured for interoperation as either a bounded or an unbounded iFCP fabric.
iFCPゲートウェイの収集はinteroperationのために境界がある骨組みか限りないiFCP骨組みとして構成されるかもしれません。
Gateways in a bounded iFCP fabric operate in address transparent mode, as described in Section 4.5. In this mode, the scope of a fibre channel N_PORT address is fabric-wide and is derived from domain IDs issued by the iSNS server from a common pool. As discussed in Section 4.3.2, the maximum number of domain IDs allowed by the fibre channel limits the configuration of a bounded iFCP fabric.
境界があるiFCP骨組みのゲートウェイはセクション4.5で説明されるようにアドレス透過モードで作動します。 このモードで、繊維チャンネルN_PORTアドレスの範囲を骨組みの全体であり、iSNSサーバによって一般的なプールから発行されたドメインIDから得ます。 セクション4.3.2で議論するように、ドメインIDの最大数は繊維チャンネル限界による境界があるiFCP骨組みの構成を許しました。
Gateways in an unbounded iFCP fabric operate in address translation mode as described in Section 4.6. In this mode, the scope of an N_PORT address is local to a gateway region. For fibre channel traffic between regions, the translation of frame-embedded N_PORT addresses is performed by the gateway. As discussed below, the number of switch elements and gateways in an unbounded iFCP fabric may exceed the limits of a conventional fibre channel fabric.
限りないiFCP骨組みのゲートウェイはセクション4.6で説明されるようにアドレス変換モードで作動します。 このモードで、N_PORTアドレスの範囲はゲートウェイ領域に地方です。 領域の間の繊維チャンネルトラフィックにおいて、Nフレームで埋め込まれた_PORTアドレスに関する翻訳はゲートウェイによって実行されます。 以下で議論するように、限りないiFCP骨組みのスイッチ素子とゲートウェイの数は従来の繊維チャンネル骨組みの限界を超えるかもしれません。
All iFCP gateways MUST support unbounded iFCP fabrics. Support for bounded iFCP fabrics is OPTIONAL.
すべてのiFCPゲートウェイが限りないiFCP骨組みを支えなければなりません。 境界があるiFCP骨組みのサポートはOPTIONALです。
The decision to support bounded iFCP fabrics in a gateway implementation depends on the address transparency, configuration scalability, and fault tolerance considerations given in the following sections.
ゲートウェイ実装における境界があるiFCP骨組みを支えるという決定は以下のセクションで与えられたアドレス透明、構成スケーラビリティ、および耐障害性問題に依存します。
4.3.1. Address Transparency
4.3.1. アドレス透明
Although iFCP gateways in an unbounded fabric will convert N_PORT addresses in the frame header and payload of standard link service messages, a gateway cannot convert such addresses in the payload of vendor- or user-specific fibre channel frame traffic.
限りない骨組みのiFCPゲートウェイは標準のリンクサービスメッセージのフレームヘッダーとペイロードのN_PORTアドレスを変換するでしょうが、ゲートウェイはベンダーのペイロードのそのようなアドレスかユーザ特有の繊維チャンネルフレームトラフィックを変換できません。
Monia, et al. Standards Track [Page 22] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[22ページ]RFC4172インターネット繊維チャンネル
Consequently, although both bounded and unbounded iFCP fabrics support standards-compliant FC-4 protocol implementations and link services used by mainstream fibre channel applications, a bounded iFCP fabric may also support vendor- or user-specific protocol and link service implementations that carry N_PORT IDs in the frame payload.
その結果、境界があるiFCP骨組みは、両方がバウンドして、限りないiFCP骨組みは、規格対応することのFC-4プロトコル実装をサポートして、主流の繊維チャンネルアプリケーションで利用されたサービスをリンクしますが、また、ベンダーかユーザ特有のプロトコルをサポートして、フレームペイロードのN_PORT IDを運ぶサービス実装をリンクするかもしれません。
4.3.2. Configuration Scalability
4.3.2. 構成スケーラビリティ
The scalability limits of a bounded fabric configuration are a consequence of the fibre channel address allocation policy discussed in Section 3.7.1. As noted, a bounded iFCP fabric using this address allocation scheme is limited to a combined total of 239 gateways and fibre channel switch elements. As the system expands, the network may grow to include many switch elements and gateways, each of which controls a small number of devices. In this case, the limitation in switch and gateway count may become a barrier to extending and fully integrating the storage network.
境界がある骨組みの構成のスケーラビリティ限界はセクション3.7.1で議論した繊維チャンネル・アドレス配分方針の結果です。 注意されるように、このアドレス配分体系を使用する境界があるiFCP骨組みは239門と繊維チャンネルスイッチ素子の結合した合計に制限されます。 システムが拡張しているのに従って、ネットワークは多くのスイッチ素子とゲートウェイを含むようになるかもしれません。それはそれぞれ少ない数のデバイスを制御します。 この場合、スイッチとゲートウェイカウントにおける制限はストレージネットワークを広げていて、完全、統合することへのバリアになるかもしれません。
Since N_PORT fibre channel addresses in an unbounded iFCP fabric are not fabric-wide, the limits imposed by fibre channel address allocation only apply within the gateway region. Across regions, the number of iFCP gateways, fibre channel devices, and switch elements that may be internetworked are not constrained by these limits. In exchange for improved scalability, however, implementations must consider the incremental overhead of address conversion, as well as the address transparency issues discussed in Section 4.3.1.
限りないiFCP骨組みのN_PORT繊維チャンネル・アドレスが骨組みの全体でないので、繊維チャンネル・アドレス配分で課された限界はゲートウェイ領域の中で適用されるだけです。 領域の向こう側に、iFCPゲートウェイ、繊維チャンネルデバイス、およびinternetworkedされるかもしれないスイッチ素子の数はこれらの限界で抑制されません。 しかしながら、改良されたスケーラビリティと引き換えに、実装はアドレス変換の増加のオーバーヘッドを考えなければなりません、セクション4.3.1で議論したアドレス透明問題と同様に。
4.3.3. Fault Tolerance
4.3.3. 耐障害性
In a bounded iFCP fabric, address reassignment caused by a fault or reconfiguration, such as the addition of a new gateway region, may cascade to other regions, causing fabric-wide disruption as new N_PORT addresses are assigned. Furthermore, before a new gateway can be merged into the fabric, its iSNS server must be slaved to the iSNS server in the bounded fabric to centralize the issuance of domain IDs. In an unbounded iFCP fabric, coordinating the iSNS databases requires only that the iSNS servers exchange client attributes with one another.
境界があるiFCP骨組みでは、新しいゲートウェイ領域の追加などの欠点か再構成によって引き起こされたアドレス再割当ては他の領域にどっと落すかもしれません、N新しい_PORTアドレスが割り当てられるので骨組みの全体の分裂を引き起こして。 その上、新しいゲートウェイに溶け込むことができる前に骨組み、iSNSサーバの身を粉にして働かなければなりません。ドメインIDの発行を集結する境界がある骨組みのiSNSサーバ。 限りないiFCP骨組みでは、iSNSデータベースを調整するのは、iSNSサーバがクライアント属性をお互いと交換するだけであるのを必要とします。
A bounded iFCP fabric also has an increased dependency on the availability of the iSNS server, which must act as the central address assignment authority. If connectivity with the server is lost, new DOMAIN_ID values cannot be automatically allocated as gateways and fibre channel switch elements are added.
また、境界があるiFCP骨組みはiSNSサーバの有用性に増強された依存を持っています。(サーバは主要なアドレス課題権威として機能しなければなりません)。 サーバがある接続性が無くなるなら、ゲートウェイと繊維チャンネルスイッチ素子が加えられるとき、自動的に新しいDOMAIN_ID値を割り当てることができません。
Monia, et al. Standards Track [Page 23] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[23ページ]RFC4172インターネット繊維チャンネル
4.4. The iFCP N_PORT Address Model
4.4. iFCP N_ポートアドレスモデル
This section discusses iFCP extensions to the fibre channel addressing model of Section 3.7.1, which are required for the transparent routing of frames between locally and remotely attached N_PORTs.
このセクションはセクション3.7.1の繊維チャンネルアドレシングモデルにiFCP拡張子について論じます。(.1が局所的でほんの少し付属しているN_PORTsの間のフレームの見え透いたルーティングに必要です)。
In the iFCP protocol, an N_PORT is represented by the following addresses:
iFCPプロトコルで、N_PORTは以下のアドレスによって表されます:
a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a locally
attached device. Depending on the gateway addressing mode, the
scope is local either to a region or to a bounded iFCP fabric. In
either mode, communications between N_PORTs in the same gateway
region use the N_PORT ID.
a) 24ビットのN_ポートID。 局所的に添付のデバイスの繊維チャンネルN_PORTアドレス。 ゲートウェイアドレッシング・モードによって、範囲は領域、または、境界があるiFCP骨組みに地方です。 モードで、同じゲートウェイ領域のN_PORTsのコミュニケーションはN_PORT IDを使用します。
b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned
by each gateway operating in address translation mode to identify
a remotely attached N_PORT. Frame traffic is intercepted by an
iFCP gateway and directed to a remotely attached N_PORT by means
of the N_PORT alias. The address assigned by each gateway is
unique within the scope of the gateway region.
b) 24ビットのN_PORT別名。 アドレスがほんの少し付属しているN_PORTを特定するためにアドレス変換モードで作動する各ゲートウェイで割り当てた繊維チャンネルN_PORT。 フレームトラフィックは、N_PORT別名によってiFCPゲートウェイによって妨害されて、ほんの少し付属しているN_PORTに向けられます。 各ゲートウェイによって割り当てられたアドレスはゲートウェイ領域の範囲の中でユニークです。
c) An N_PORT network address. A tuple consisting of the gateway IP
address, TCP port number, and N_PORT ID. The N_PORT network
address identifies the source and destination N_PORTs for fibre
channel traffic on the IP network.
c) N_PORTネットワーク・アドレス。 tupleがゲートウェイIPアドレスから成って、TCPは数、およびN_PORT IDを移植します。 N_PORTネットワーク・アドレスはIPの繊維チャンネルトラフィックのためのN_PORTsがネットワークでつなぐソースと目的地を特定します。
To provide transparent communications between a remote and local N_PORT, a gateway MUST maintain an iFCP session descriptor (see Section 5.2.2.2) reflecting the association between the fibre channel address representing the remote N_PORT and the remote device's N_PORT network address. To establish this association, the iFCP gateway assigns and manages fibre channel N_PORT fabric addresses as described in the following paragraphs.
リモートで地方のN_PORTの見え透いたコミュニケーションを提供するために、ゲートウェイはiFCPセッション記述子を主張しなければなりません。(繊維チャンネルの間の協会が扱うセクション5.2.2.2)反射がリモートN_PORTと遠隔装置のN_PORTネットワーク・アドレスを表しているのを見てください。 iFCPゲートウェイは、この協会を証明するために、以下のパラグラフで説明されるように繊維チャンネルN_PORT骨組みのアドレスを割り当てて、管理します。
In an iFCP fabric, the iFCP gateway performs the address assignment and frame routing functions of an FC switch element. Unlike an FC switch, however, an iFCP gateway must also direct frames to external devices attached to remote gateways on the IP network.
iFCP骨組みでは、iFCPゲートウェイは、FCスイッチ素子の関数を発送しながら、アドレス課題とフレームを実行します。 しかしながら、FCスイッチと異なって、iFCPゲートウェイはまた、IPネットワークにリモートゲートウェイに取り付けられた外部のデバイスにフレームを向けなければなりません。
In order to be transparent to FC devices, the gateway must deliver such frames using only the 24-bit destination address in the frame header. By exploiting its control of address allocation and access to frame traffic entering or leaving the gateway region, the gateway is able to achieve the necessary transparency.
FCデバイスに透明になるように、ゲートウェイはフレームヘッダーで24ビットの送付先アドレスだけを使用することでそのようなフレームを提供しなければなりません。 ゲートウェイ領域を入るか、または出て、トラフィックを縁どるのにアドレス配分とアクセスのコントロールを利用することによって、ゲートウェイは必要な透明を達成できます。
Monia, et al. Standards Track [Page 24] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[24ページ]RFC4172インターネット繊維チャンネル
N_PORT addresses within a gateway region may be allocated in one of two ways:
2つの方法の1つでゲートウェイ領域の中のN_PORTアドレスを割り当てるかもしれません:
a) Address Translation Mode - A mode of N_PORT address assignment in
which the scope of an N_PORT fibre channel address is unique to
the gateway region. The address of a remote device is represented
in that gateway region by its gateway-assigned N_PORT alias.
a) Translation Modeを扱ってください--N_PORT繊維チャンネル・アドレスの範囲がゲートウェイ領域にユニークであるN_PORTアドレス課題の方法。 遠隔装置のアドレスはそのゲートウェイ領域にゲートウェイで割り当てられたN_PORT別名によって表されます。
b) Address Transparent Mode - A mode of N_PORT address assignment in
which the scope of an N_PORT fibre channel address is unique
across the set of gateway regions comprising a bounded iFCP
fabric.
b) Transparent Modeを扱ってください--N_PORT繊維チャンネル・アドレスの範囲が境界があるiFCP骨組みを包括しながらゲートウェイ領域のセットの向こう側にユニークであるN_PORTアドレス課題の方法。
In address transparent mode, gateways within a bounded fabric cooperate in the assignment of addresses to locally attached N_PORTs. Each gateway in control of a region is responsible for obtaining and distributing unique domain IDs from the address assignment authority, as described in Section 4.5.1. Consequently, within the scope of a bounded fabric, the address of each N_PORT is unique. For that reason, gateway-assigned aliases are not required for representing remote N_PORTs.
アドレスでは、透過モード、境界がある骨組みの中のゲートウェイが局所的に添付のN_PORTsへのアドレスの課題に協力します。 領域のコントロールにおけるそれぞれのゲートウェイはアドレス課題権威からユニークなドメインIDを得て、分配するのに原因となります、セクション4.5.1で説明されるように。 その結果、境界がある骨組みの範囲の中では、それぞれのN_PORTのアドレスはユニークです。 その理由で、ゲートウェイで割り当てられた別名は、リモートN_PORTsを表すのに必要ではありません。
All iFCP implementations MUST support operations in address translation mode. Implementation of address transparent mode is OPTIONAL but, of course, must be provided if bounded iFCP fabric configurations are to be supported.
すべてのiFCP実装がアドレス変換モードにおける操作をサポートしなければなりません。 アドレス透過モードの実装をOPTIONALですが、境界があるiFCP骨組みの構成がサポートすることであるならもちろん提供しなければなりません。
The mode of gateway operation is settable in an implementation- specific manner. The implementation MUST NOT:
ゲートウェイ操作のモードは実装の特定の方法で「舗装用敷石-可能」です。 実装はそうしてはいけません:
a) allow the mode to be changed after the gateway begins processing
fibre channel frame traffic,
a) ゲートウェイが繊維チャンネルフレームトラフィックを処理し始めた後にモードを変えさせてください。
b) permit operation in more than one mode at a time, or
またはb) 一度に1つ以上のモードで操作の入るのを許してください。
c) establish an iFCP session with a gateway that is not in the same
mode.
c) 同じモードでないゲートウェイとのiFCPセッションを確立してください。
4.5. Operation in Address Transparent Mode
4.5. アドレス透過モードにおける操作
The following considerations and requirements apply to this mode of operation:
以下の問題と要件はこの運転モードに適用されます:
a) iFCP gateways in address transparent mode will not interoperate
with iFCP gateways that are not in address transparent mode.
a) 中にそうしないiFCPゲートウェイがある状態で透過モードが共同利用しない住所のiFCPゲートウェイは透過モードを扱います。
Monia, et al. Standards Track [Page 25] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[25ページ]RFC4172インターネット繊維チャンネル
b) When interoperating with locally attached fibre channel switch
elements, each iFCP gateway MUST assume control of DOMAIN_ID
assignments in accordance with the appropriate fibre channel
standard or vendor-specific protocol specification. As described
in Section 4.5.1, DOMAIN_ID values that are assigned to FC
switches internal to the gateway region must be issued by the iSNS
server.
b) 局所的に添付の繊維チャンネルスイッチ素子で共同利用するとき、それぞれのiFCPゲートウェイは適切な繊維チャンネル規格かベンダー独自のプロトコル仕様通りにDOMAIN_ID課題のコントロールを仮定しなければなりません。 セクション4.5.1で説明されるように、iSNSサーバでゲートウェイ領域への内部のFCスイッチに割り当てられるDOMAIN_ID値を発行しなければなりません。
c) When operating in address transparent Mode, fibre channel address
translation SHALL NOT take place.
c) アドレスで透明なModeを操作するとき、繊維チャンネルアドレス変換SHALL NOTは行われます。
When operating in address transparent mode, however, the gateway MUST establish and maintain the context of each iFCP session in accordance with Section 5.2.2.
アドレス透過モードで作動するとき、セクション5.2.2に従って、しかしながら、ゲートウェイは、それぞれのiFCPセッションの文脈を確立して、維持しなければなりません。
4.5.1. Transparent Mode Domain ID Management
4.5.1. 透過モードドメインID管理
As described in Section 4.5, each gateway and fibre channel switch in a bounded iFCP fabric has a unique domain ID. In a gateway region containing fibre channel switch elements, each element obtains a domain ID by querying the principal switch as described in [FC-SW2] -- in this case, the iFCP gateway itself. The gateway, in turn, obtains domain IDs on demand from the iSNS name server acting as the central address allocation authority. In effect, the iSNS server assumes the role of principal switch for the bounded fabric. In that case, the iSNS database contains:
セクション4.5で説明されるように、境界があるiFCP骨組みのそれぞれのゲートウェイと繊維チャンネルスイッチにはユニークなドメインIDがあります。 繊維チャンネルスイッチ素子を含むゲートウェイ領域では、各要素がこの場合[FC-SW2]で説明されるように主要なスイッチについて質問することによって、ドメインIDを得ます、iFCPゲートウェイ自体。 ゲートウェイは主要なアドレス配分権威として機能するiSNSネームサーバからオンデマンドのドメインIDを順番に得ます。 事実上、iSNSサーバは境界がある骨組みのために主要なスイッチの役割を引き受けます。 その場合、iSNSデータベースは以下を含んでいます。
a) The definition for one or more bounded iFCP fabrics, and
a) そして1つ以上の境界があるiFCP骨組みのための定義。
b) For each bounded fabric, a worldwide-unique name identifying each
gateway in the fabric. A gateway in address transparent mode MUST
reside in one, and only one, bounded fabric.
b) それぞれの境界がある骨組み、骨組みの各ゲートウェイを特定する世界的なユニークな名前のために。 アドレス透過モードのゲートウェイは1、および1だけ、境界がある骨組みに住んでいなければなりません。
As the Principal Switch within the gateway region, an iFCP gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by issuing the appropriate iSNS query, using its worldwide name.
プリンシパルとして、ゲートウェイ領域の中のSwitch、アドレス透過モードSHALLのiFCPゲートウェイは適切なiSNS質問を発行することによって、ゲートウェイ領域での使用としてドメインIDを得ます、世界的な名前を使用して。
4.5.2. Incompatibility with Address Translation Mode
4.5.2. アドレス変換モードがある不一致
Except for the session control frames specified in Section 6, iFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRP bit set to one in the iFCP flags field of the encapsulation header (see Section 5.3.1). The iFCP gateway SHALL immediately terminate all iFCP sessions with the iFCP gateway from which it receives such frames.
セクション6で指定されたセッション制御フレームを除いて、アドレス透過モードSHALL NOTのiFCPゲートウェイは、旗がさばくカプセル化ヘッダーのiFCPの1つにTRPビットを設定しないフレームを、溯源するか、または受け入れます(セクション5.3.1を見てください)。 iFCPゲートウェイSHALLはすぐに、それがそのようなフレームを受けるiFCPゲートウェイとのすべてのiFCPセッションを終えます。
Monia, et al. Standards Track [Page 26] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[26ページ]RFC4172インターネット繊維チャンネル
4.6. Operation in Address Translation Mode
4.6. アドレス変換モードにおける操作
This section describes the process for managing the assignment of addresses within a gateway region that is part of an unbounded iFCP fabric, including the modification of FC frame addresses embedded in the frame header for frames sent and received from remotely attached N_PORTs.
このセクションは限りないiFCP骨組みの一部であるゲートウェイ領域の中でアドレスの課題を管理するためにプロセスについて説明します、ほんの少し付属しているN_PORTsから送られて、受け取られたフレームのためにフレームヘッダーに埋め込まれたFCフレームアドレスの変更を含んでいて。
As described in Section 4.4, the scope of N_PORT addresses in this mode is local to the gateway region. A principal switch within the gateway region, possibly the iFCP gateway itself, oversees the assignment of such addresses, in accordance with the rules specified in [FC-FS] and [FC-FLA].
セクション4.4で説明されるように、このモードによるN_PORTアドレスの範囲はゲートウェイ領域に地方です。 ゲートウェイ領域の中の主要なスイッチ(ことによるとiFCPゲートウェイ自体)はそのようなアドレスの課題を監督します、[FC-FS]と[FC-FLA]で指定された規則に従って。
The assignment of N_PORT addresses to locally attached devices is controlled by the switch element to which the device is connected.
局所的に添付のデバイスへのN_PORTアドレスの課題はデバイスが関連しているスイッチ素子によって制御されます。
The assignment of N_PORT addresses for remotely attached devices is controlled by the gateway by which the remote device is accessed. In this case, the gateway MUST assign a locally significant N_PORT alias to be used in place of the N_PORT ID assigned by the remote gateway. The N_PORT alias is assigned during device discovery, as described in Section 5.2.2.1.
ほんの少し付属しているデバイスのためのN_PORTアドレスの課題は遠隔装置がアクセスされているゲートウェイによって制御されます。 この場合、ゲートウェイは、リモートゲートウェイによって割り当てられたN_PORT IDに代わって使用されるために局所的に重要なN_PORT別名を割り当てなければなりません。 N_PORT別名はデバイス発見の間、セクション5.2.2で.1に説明されるように割り当てられます。
To perform address conversion and to enable the appropriate routing, the gateway MUST establish an iFCP session and generate the information required to map each N_PORT alias to the appropriate TCP/IP connection context and N_PORT ID of the remotely accessed N_PORT. These mappings are created and updated by means specified in Section 5.2.2.2. As described in that section, the required mapping information is represented by the iFCP session descriptor reproduced in Figure 8.
ゲートウェイは、アドレス変換を実行して、適切なルーティングを可能にするために、iFCPセッションを確立して、離れてアクセスされたN_PORTの適切なTCP/IP接続関係とN_PORT IDにそれぞれのN_PORT別名を写像するのに必要である情報を生成しなければなりません。 セクション5.2.2で.2に指定された手段で、これらのマッピングを作成して、アップデートします。 そのセクションで説明されるように、必要なマッピング情報は図8で再生したiFCPセッション記述子によって表されます。
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
+-----------------------+ |TCP接続文脈| +-----------------------+ | ローカルのN_ポートID| +-----------------------+ | リモートN_ポートID| +-----------------------+ | リモートN_ポート別名| +-----------------------+
Figure 8. iFCP Session Descriptor (from Section 5.2.2.2)
エイト環iFCPセッション記述子(セクション5.2.2、.2)
Monia, et al. Standards Track [Page 27] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[27ページ]RFC4172インターネット繊維チャンネル
Except for frames comprising special link service messages (see Section 7.2), outbound frames are encapsulated and sent without modification. Address translation is deferred until receipt from the IP network, as specified in Section 4.6.1.
特別なリンクサービスメッセージ(セクション7.2を見る)を包括するフレームを除いて、変更なしで外国行きのフレームをカプセル化して、送ります。 アドレス変換はセクション4.6.1で指定されるようにIPネットワークからの領収書まで延期されます。
4.6.1. Inbound Frame Address Translation
4.6.1. 本国行きのフレームアドレス変換
For inbound frames received from the IP network, the receiving gateway SHALL reference the session descriptor to fill in the D_ID field with the destination N_PORT ID and the S_ID field with the N_PORT alias it assigned. The translation process for inbound frames is shown in Figure 9.
IPネットワーク、受信から受け取られた本国行きのフレームに関しては、ゲートウェイSHALL参照の目的地N_PORT IDと共にD_ID分野に記入するセッション記述子とS_IDはNと共に_それが割り当てたPORT別名をさばきます。 本国行きのフレームへの翻訳プロセスは図9で見せられます。
Network Format of Inbound Frame
+--------------------------------------------+ iFCP
| FC Encapsulation Header | Session
+--------------------------------------------+ Descriptor
| SOF Delimiter Word | |
+========+===================================+ V
| | D_ID Field | +--------+-----+
+--------+-----------------------------------+ | Lookup source|
| | S_ID Field | | N_PORT Alias |
+--------+-----------------------------------+ | and |
| Control Information, Payload, | | destination |
| and FC CRC | | N_PORT ID |
| | +--------+-----+
| | |
| | |
+============================================+ |
| EOF Delimiter Word | |
+--------------------------------------------+ |
|
|
Frame after Address Translation and De-encapsulation |
+--------+-----------------------------------+ |
| | Destination N_PORT ID |<-------------+
+--------+-----------------------------------+ |
| | Source N_PORT Alias |<-------------+
+--------+-----------------------------------+
| |
| Control information, Payload, |
| and FC CRC |
+--------------------------------------------+
本国行きのフレーム+のネットワーク形式--------------------------------------------+ iFCP| FCカプセル化ヘッダー| セッション+--------------------------------------------+ 記述子| SOFデリミタWord| | +========+===================================+ V| | D_ID分野| +--------+-----+ +--------+-----------------------------------+ | ルックアップソース| | | S_ID分野| | N_ポート別名| +--------+-----------------------------------+ | そして| | 情報、有効搭載量を制御してください。| | 目的地| | そして、FC CRC| | N_ポートID| | | +--------+-----+ | | | | | | +============================================+ | | EOFデリミタWord| | +--------------------------------------------+ | | | アドレスの後に翻訳と反-カプセル化を縁どってください。| +--------+-----------------------------------+ | | | 目的地N_はIDを移植します。| <、-、-、-、-、-、-、-、-、-、-、-、--+ +--------+-----------------------------------+ | | | ソースN_はアリアを移植します。| <、-、-、-、-、-、-、-、-、-、-、-、--+ +--------+-----------------------------------+ | | | 情報、有効搭載量を制御してください。| | そして、FC CRC| +--------------------------------------------+
Figure 9. Inbound Frame Address Translation
図9。 本国行きのフレームアドレス変換
Monia, et al. Standards Track [Page 28] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[28ページ]RFC4172インターネット繊維チャンネル
The receiving gateway SHALL consider the contents of the S_ID and D_ID fields to be undefined when received. After replacing these fields, the gateway MUST recalculate the FC CRC.
受け取ると、受信ゲートウェイSHALLは、S_IDとD_ID分野のコンテンツが未定義であると考えます。 これらの野原を取り替えた後に、ゲートウェイはFC CRCについて再計算しなければなりません。
4.6.2. Incompatibility with Address Transparent Mode
4.6.2. アドレス透過モードがある不一致
iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRP bit set to one in the iFCP flags field of the encapsulation header. The iFCP gateway SHALL immediately abort all iFCP sessions with the iFCP gateway from which it receives frames such as those described in Section 5.2.3.
アドレス変換モードSHALL NOTによるiFCPゲートウェイは、旗がさばくカプセル化ヘッダーのiFCPの1つにTRPビットを設定するフレームを、溯源するか、または受け入れます。 iFCPゲートウェイSHALLはすぐに、それがセクション5.2.3で説明されたものなどのようにフレーム搬入するiFCPゲートウェイとのすべてのiFCPセッションを中止します。
5. iFCP Protocol
5. iFCPプロトコル
5.1. Overview
5.1. 概要
5.1.1. iFCP Transport Services
5.1.1. iFCP輸送サービス
The main function of the iFCP protocol layer is to transport fibre channel frame images between locally and remotely attached N_PORTs.
iFCPプロトコル層の主な関数は局所的でほんの少し付属しているN_PORTsの間の繊維チャンネルフレームイメージを輸送することです。
When transporting frames to a remote N_PORT, the iFCP layer encapsulates and routes the fibre channel frames comprising each fibre channel Information Unit via a predetermined TCP connection for transport across the IP network.
リモートN_PORTにフレームを輸送するとき、iFCP層は、IPネットワークの向こう側に輸送のための予定されたTCP接続で各繊維チャンネル情報Unitを包括する繊維チャンネルフレームを、カプセル化して、発送します。
When receiving fibre channel frame images from the IP network, the iFCP layer de-encapsulates and delivers each frame to the appropriate N_PORT.
IPネットワークから繊維チャンネルフレームイメージを受け取るとき、iFCP層は、適切なN_PORTに各フレームを反-カプセル化して、提供します。
The iFCP layer processes the following types of traffic:
iFCP層は以下のタイプのトラフィックを処理します:
a) FC-4 frame images associated with a fibre channel application
protocol.
a) 繊維チャンネルアプリケーションに関連しているFC-4フレームイメージは議定書を作ります。
b) FC-2 frames comprising fibre channel link service requests and
responses.
b) FC-2は繊維チャンネルリンクサービスのリクエストを包括して、応答を縁どっています。
c) Fibre channel broadcast frames.
c) 繊維チャンネルはフレームを放送しました。
d) iFCP control messages required to set up, manage, or terminate an
iFCP session.
d)iFCPコントロールメッセージがiFCPセッションをセットアップするか、管理するか、または終えるのが必要です。
For FC-4 N_PORT traffic and most FC-2 messages, the iFCP layer never interprets the contents of the frame payload.
FC-4 N_に関しては、トラフィックとほとんどのFC-2メッセージ、iFCPが層にするPORTはフレームペイロードのコンテンツを決して解釈しません。
iFCP does interpret and process iFCP control messages and certain link service messages, as described in Section 5.1.2.
iFCPはセクション5.1.2で説明されるようにiFCPコントロールメッセージとあるリンクサービスメッセージを解釈して、処理します。
Monia, et al. Standards Track [Page 29] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[29ページ]RFC4172インターネット繊維チャンネル
5.1.2. iFCP Support for Link Services
5.1.2. リンクサービスのiFCPサポート
iFCP must intervene in the processing of those fibre channel link service messages that contain N_PORT addresses in the message payload or that require other special handling, such as an N_PORT login request (PLOGI).
iFCPはメッセージペイロードのN_PORTアドレスを含むか、または他の特別な取り扱いを必要とするそれらの繊維チャンネルリンクサービスメッセージの処理を干渉しなければなりません、N_PORTログイン要求(PLOGI)のように。
In the former case, an iFCP gateway operating in address translation mode MUST supplement the payload with additional information that enables the receiving gateway to convert such embedded N_PORT addresses to its frame of reference.
前の場合では、アドレス変換モードで作動するiFCPゲートウェイは受信ゲートウェイがそのようなN埋め込まれた_PORTアドレスを基準系に変換するのを可能にする追加情報でペイロードを補わなければなりません。
For out bound fibre channel frames comprising such a link service, the iFCP layer creates the supplemental information based on frame content, modifies the frame payload, and then transmits the resulting fibre channel frame with supplemental data through the appropriate TCP connection.
そのようなリンクサービスを包括する繊維チャンネルフレームが外でバウンドしていて、iFCP層が補足のデータで適切なTCP接続でフレーム内容に基づく補足的情報を作成して、フレームペイロードを変更して、次に、結果として起こる繊維チャンネルフレームを伝えるので。
For incoming iFCP frames containing supplemented fibre channel link service frames, iFCP must interpret the frame, including any supplemental information, modify the frame content, and forward the resulting frame to the destination N_PORT for further processing.
補われた繊維チャンネルリンクサービスフレームを含む入って来るiFCPフレームに関しては、iFCPはさらなる処理のために目的地N_PORTにどんな補足的情報も含むフレームを解釈して、フレーム内容を変更して、結果として起こるフレームを送らなければなりません。
Section 7.1 describes the processing of these link service messages in detail.
セクション7.1は詳細にこれらのリンクサービスメッセージの処理について説明します。
5.2. TCP Stream Transport of iFCP Frames
5.2. iFCPフレームのTCPストリーム輸送
5.2.1. iFCP Session Model
5.2.1. iFCPセッションモデル
An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. No more than one iFCP session SHALL exist between a given pair of N_PORTs.
iFCPセッションはただ一つのTCP/IP接続によって接合されたセッション終点を包括するN_PORTsの組から成ります。 1iFCPのセッションSHALLは与えられた組のN_PORTsの間に存在しています。
An N_PORT is identified by its network address, consisting of:
以下から成って、N_PORTはネットワーク・アドレスによって特定されます。
a) the N_PORT ID assigned by the gateway to which the N_PORT is
locally attached, and
そしてa) N_PORTが局所的に取り付けられるゲートウェイによって割り当てられたN_PORT ID。
b) the iFCP Portal address, consisting of its IP address and TCP port
number.
IPアドレスから成って、iFCP Portalが扱うb)とTCPは数を移植します。
Because only one iFCP session may exist between a pair of N_PORTs, the iFCP session is uniquely identified by the network addresses of the session end points.
1つのiFCPセッションだけが1組のN_PORTsの間に存在するかもしれないので、iFCPセッションはセッションエンドポイントのネットワーク・アドレスによって唯一特定されます。
TCP connections that may be used for iFCP sessions between pairs of iFCP portals are either "bound" or "unbound". An unbound connection
組のiFCP入り口の間のiFCPセッションに使用されるかもしれないTCP接続は、「制限される」か「自由です」。 無限の接続
Monia, et al. Standards Track [Page 30] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[30ページ]RFC4172インターネット繊維チャンネル
is a TCP connection that is not actively supporting an iFCP session. A gateway implementation MAY establish a pool of unbound connections to reduce the session setup time. Such pre-existing TCP connections between iFCP Portals remain unbound and uncommitted until allocated to an iFCP session through a CBIND message (see Section 6.1).
TCPは活発にiFCPセッションをサポートしていない接続ですか? ゲートウェイ実装は、セッション準備時間を短縮するために無限の接続のプールを設立するかもしれません。 そのような先在のTCP接続はiFCP Portalsの間にCBINDメッセージを通してiFCPセッションまで割り当てるまで自由であって、未遂で留まっています(セクション6.1を見てください)。
When the iFCP layer creates an iFCP session, it may select an existing unbound TCP connection or establish a new TCP connection and send the CBIND message down that TCP connection. This allocates the TCP connection to that iFCP session.
iFCP層がiFCPセッションを作成するとき、それは、既存の無限のTCP接続を選ぶか、新しいTCP接続を確立して、またはそのTCP接続の下側にCBINDメッセージを送るかもしれません。 これはそのiFCPセッションまでTCP接続を割り当てます。
5.2.2. iFCP Session Management
5.2.2. iFCPセッション管理
This section describes the protocols and data structures required to establish and terminate an iFCP session.
このセクションはプロトコルについて説明して、データ構造がiFCPセッションを確立して、終えるのが必要です。
5.2.2.1. The Remote N_PORT Descriptor
5.2.2.1. リモートN_ポート記述子
In order to establish an iFCP session, an iFCP gateway MUST maintain information allowing it to locate a remotely attached N_PORT. For explanatory purposes, such information is assumed to reside in a descriptor with the format shown in Figure 10.
iFCPセッションを確立するために、iFCPゲートウェイはそれがほんの少し付属しているN_PORTの場所を見つけることができる情報を保守しなければなりません。 説明している目的のために、そのような情報が図10に示される書式での記述子に住んでいると思われます。
+--------------------------------+
| N_PORT Worldwide Unique Name |
+--------------------------------+
| iFCP Portal Address |
+--------------------------------+
| N_PORT ID of Remote N_PORT |
+--------------------------------+
| N_PORT Alias |
+--------------------------------+
+--------------------------------+ | N_のポートの世界的なユニークな名| +--------------------------------+ | iFCP入り口のアドレス| +--------------------------------+ | 遠く離れたN_ポートのN_ポートID| +--------------------------------+ | N_ポート別名| +--------------------------------+
Figure 10. Remote N_PORT Descriptor
図10。 リモートN_ポート記述子
Each descriptor aggregates the following information about a remotely attached N_PORT:
各記述子はほんの少し付属しているN_PORTの周りで以下の情報に集められます:
N_PORT Worldwide Unique Name -- 64-bit N_PORT worldwide name as
specified in [FC-FS]. A Remote N_PORT descriptor is uniquely
identified by this parameter.
N_PORT Worldwide Unique Name--世界中のPORTが[FC-FS]で指定されるように命名する64ビットのN_。 Remote N_PORT記述子はこのパラメタによって唯一特定されます。
iFCP Portal Address -- The IP address and TCP port number
referenced when creation of the TCP connection associated with an
iFCP session is requested.
iFCP Portal Address--IPのアドレスとTCPはiFCPセッションに関連づけられたTCP接続の作成が要求されているとき参照をつけられる数を移植します。
N_PORT ID -- N_PORT fibre channel address assigned to the remote
device by the remote iFCP gateway.
N_PORT ID--リモートiFCPゲートウェイによって遠隔装置に割り当てられたN_PORT繊維チャンネル・アドレス。
Monia, et al. Standards Track [Page 31] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[31ページ]RFC4172インターネット繊維チャンネル
N_PORT Alias -- N_PORT fibre channel address assigned to the
remote device by the 'local' iFCP gateway when it operates in
address translation mode.
N_PORTアリア--アドレス変換モードで作動すると'地方'のiFCPゲートウェイによって遠隔装置に割り当てられたN_PORT繊維チャンネル・アドレス。
An iFCP gateway SHALL have one and only one descriptor for each remote N_PORT it accesses. If a descriptor does not exist, one SHALL be created using the information returned by an iSNS name server query. Such queries may result from:
iFCPゲートウェイSHALLには、唯一無二のそれぞれのリモートN_PORTあたり1つの記述子があります。それはアクセスします。 1SHALL、記述子がそうしないなら、存在してください。iSNSネームサーバ質問で返して、情報を使用することで、作成されてください。 そのような質問は以下から生じるかもしれません。
a) a fibre channel Name Server request originated by a locally
attached N_PORT (see Sections 3.5 and 9.3), or
またはa) Name Serverが要求する繊維チャンネルが局所的に添付のN_PORTで起因した、(セクション3.5と9.3を見てください)。
b) a CBIND request received from a remote fibre channel device (see
Section 5.2.2.2).
セクション5.2を見てください。CBIND要求がリモート繊維チャンネルデバイスから受けたb)、(.2 .2)。
When creating a descriptor in response to an incoming CBIND request, the iFCP gateway SHALL perform an iSNS name server query using the worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME field within the CBIND payload. The descriptor SHALL be filled in using the query results.
入って来るCBIND要求に対応して記述子を作成するとき、iFCPゲートウェイSHALLは、CBINDペイロードの中にSOURCE N_PORT NAME分野で世界的なポート名(リモートN_PORT)を使用することでiSNSネームサーバ質問を実行します。 記述子SHALL、質問結果を使用することで、記入されてください。
After creating the descriptor, a gateway operating in address translation mode SHALL create and add the 24-bit N_PORT alias.
記述子を作成するアドレスで作動するゲートウェイの後に、翻訳モードSHALLは24ビットのN_PORT別名を作成して、加えます。
5.2.2.1.1. Updating a Remote N_PORT Descriptor
5.2.2.1.1. リモートN_ポート記述子をアップデートします。
A Remote N_PORT descriptor SHALL only be updated as the result of an iSNS query to obtain information for the specified worldwide port name or from information returned by an iSNS state change notification. Following such an update, a new N_PORT alias SHALL NOT be assigned.
_PORT記述子SHALLを指定された世界的なポート名のための情報を得るiSNS質問の結果としてアップデートするか、または情報iSNS州の変更届出書で返すだけであるRemote N。 そのようなアップデート、新しいN_PORT別名SHALL NOTに続く、割り当てられてください。
Before such an update, the contents of a descriptor may have become stale because of an event that invalidated or triggered a change in the N_PORT network address of the remote device, such as a fabric reconfiguration or the device's removal or replacement.
そのようなアップデートの前に、記述子のコンテンツは遠隔装置のN_PORTネットワーク・アドレスにおける変化の無効にしたか、または引き金となったイベントのために聞き古したであるなったかもしれません、デバイスの骨組みの再構成、取り外しまたは交換のように。
A collateral effect of such an event is that a fibre channel device that has been added or whose N_PORT ID has changed will have no active N_PORT logins. Consequently, FC-4 traffic directed to such an N_PORT, because of a stale descriptor, will be rejected or discarded.
そのようなイベントの傍系の効果は加えられるか、またはN_PORT IDが変化した繊維チャンネルデバイスがN活発な_PORTログインを持たないということです。 その結果、FC-4トラフィックは、聞き古した記述子のためにそのようなN_PORTに向けられるか、拒絶されるか、または捨てられるでしょう。
Once the originating N_PORT learns of the reconfiguration, usually through the name server state change notification mechanism, information returned in the notification or the subsequent name server lookup needed to reestablish the iFCP session will automatically purge such stale data from the gateway.
一度、由来しているN_PORTは、iFCPセッションがそのような聞き古したデータからゲートウェイから自動的に追放することを通知かその後のネームサーバルックアップで返された情報が通常ネームサーバ州の変更届出書メカニズムを通して回復する必要があった再構成を学びます。
Monia, et al. Standards Track [Page 32] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[32ページ]RFC4172インターネット繊維チャンネル
5.2.2.1.2. Deleting a Remote N_PORT Descriptor
5.2.2.1.2. リモートN_ポート記述子を削除します。
Deleting a remote N_PORT descriptor is equivalent to freeing up the corresponding N_PORT alias for reuse. Consequently, the descriptor MUST NOT be deleted while there are any iFCP sessions that reference the remote N_PORT.
リモートN_PORT記述子を削除するのは再利用のために対応するN_PORT別名を開けるのに同等です。 その結果、リモートN_PORTに参照をつけるどんなiFCPセッションもある間、記述子を削除してはいけません。
Descriptors eligible for deletion should be removed based on a last in, first out policy.
削除に、適任の記述子は最後のコネ、最初の出ている方針に基づいて取り除かれるべきです。
5.2.2.2. Creating an iFCP Session
5.2.2.2. iFCPセッションを作成します。
An iFCP session may be in one of the following states:
iFCPセッションが以下の州の1つにあるかもしれません:
OPEN -- The session state in which fibre channel frame images
may be sent and received.
オープン--どの繊維チャンネルフレームイメージでセッション状態を送って、受け取るかもしれないか。
OPEN PENDING -- The session state after a gateway has issued a
CBIND request but no response has yet been received. No fibre
channel frames may be sent.
OPEN PENDING--CBIND要求を発行しますが、ゲートウェイがどんな応答も発行していなかった後にまだセッション状態を受け取っています。 繊維チャンネルフレームを全く送らないかもしれません。
The session may be initiated in response to a PLOGI ELS (see Section 7.3.1.7) or for any other implementation-specific reason.
セッションはPLOGI ELSに対応して開始されるかもしれません。(セクション7.3.1の.7か)いかなる他のも、実現特有の理由がわかってください。
The gateway SHALL create the iFCP session as follows:
ゲートウェイSHALLは以下のiFCPセッションを作成します:
a) Locate the remote N_PORT descriptor corresponding to the session
end point. If the session is created in order to forward a fibre
channel frame, then the session endpoint may be obtained by
referencing the remote N_PORT alias contained in the frame header
D_ID field. If no descriptor exists, an iFCP session SHALL NOT be
created.
a) セッションエンドポイントに対応するリモートN_PORT記述子の場所を見つけてください。 繊維チャンネルフレームを進めるためにセッションを作成するなら、フレームヘッダーD_ID分野に保管されていたリモートN_PORT別名に参照をつけることによって、セッション終点を得るかもしれません。 記述子はいいえなら存在していて、iFCPセッションはSHALL NOTです。作成されます。
b) Allocate a TCP connection to the gateway to which the remote
N_PORT is locally attached. An implementation may use an existing
connection in the Unbound state, or a new connection may be
created and placed in the Unbound state.
b) リモートN_PORTが局所的に取り付けられるゲートウェイにTCP接続を割り当ててください。 実現がUnbound状態で既存の接続を使用するかもしれないか、新しい接続は、Unbound状態に創造されて、置かれるかもしれません。
When a connection is created, the IP address and TCP Port number
SHALL be obtained by referencing the remote N_PORT descriptor as
specified in Section 5.2.2.1.
接続が創造されて、IPが演説であり、TCP Port番号がSHALLであるときには、.1にセクション5.2.2における指定されるとしてのリモートN_PORT記述子に参照をつけることによって、得てください。
c) If the TCP connection cannot be allocated or cannot be created due
to limited resources, the gateway SHALL terminate session
creation.
c) TCP接続を割り当てることができないか、または限りある資源のため創造できないなら、ゲートウェイSHALLはセッション創造を終えます。
Monia, et al. Standards Track [Page 33] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[33ページ]RFC4172インターネット繊維チャンネル
d) If the TCP connection is aborted for any reason before the iFCP
session enters the OPEN state, the gateway SHALL respond in
accordance with Section 5.2.3 and MAY terminate the attempt to
create a session or MAY try to establish the TCP connection again.
d) どんな理由でも、iFCPセッションがオープン状態に入る前に、TCP接続が中止されるなら、セクション5.2.3に従ってSHALLが反応させるゲートウェイと5月は、セッションを作成する試みを終えようとするか、または再びTCP接続を確立しようとするかもしれません。
e) The gateway SHALL then issue a CBIND session control message (see
Section 6.1) and place the session in the OPEN PENDING state.
e) ゲートウェイSHALLは次に、CBINDセッション制御メッセージ(セクション6.1を見る)を発行して、OPEN PENDING状態にセッションを置きます。
f) If a CBIND response is returned with a status other than "Success"
or "iFCP session already exists", the session SHALL be terminated,
and the TCP connection returned to the Unbound state.
f) 終えられて、「成功」か「iFCPセッションは既に存在している」セッションSHALL以外の状態と共にCBIND応答を返して、TCP接続がUnbound状態に戻ったなら。
g) A CBIND STATUS of "iFCP session already exists" indicates that the
remote gateway has concurrently initiated a CBIND request to
create an iFCP session between the same pair of N_PORTs. A
gateway receiving such a response SHALL terminate this attempt and
process the incoming CBIND request in accordance with Section
5.2.2.3.
g) 「iFCPセッションは既に存在する」CBIND STATUSが、リモートゲートウェイが同時に同じ組のN_PORTsの間のiFCPセッションを作成するというCBIND要求を開始しているのを示します。 そのような応答SHALLを受けるゲートウェイはセクション5.2.2に従って入って来るCBINDが.3に要求するこの試みと過程を終えます。
h) In response to a CBIND STATUS of "Success", the gateway SHALL
place the session in the OPEN state.
h) 「成功」のCBIND STATUSに対応して、ゲートウェイSHALLはオープン状態にセッションを置きます。
Once the session is placed in the OPEN state, an iFCP session descriptor SHALL be created, containing the information shown in Figure 11:
かつて、セッションはオープン状態に置かれて、iFCPセッション記述子は作成されて、図11に示された情報を含むSHALLです:
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
+-----------------------+ |TCP接続文脈| +-----------------------+ | ローカルのN_ポートID| +-----------------------+ | リモートN_ポートID| +-----------------------+ | リモートN_ポート別名| +-----------------------+
Figure 11. iFCP Session Descriptor
図11 iFCPセッション記述子
TCP Connection Context -- Information required to identify the TCP
connection associated with the iFCP session.
TCP Connection Context--情報が接続が関連づけたTCPをiFCPセッションと同一視するのが必要です。
Local N_PORT ID -- N_PORT ID of the locally attached fibre
channel device.
地方のN_PORT ID--局所的に添付の繊維チャンネル装置のN_PORT ID。
Remote N_PORT ID -- N_PORT ID assigned to the remote device by the
remote gateway.
リモートN_PORT ID--リモートゲートウェイによって遠隔装置に割り当てられたN_PORT ID。
Monia, et al. Standards Track [Page 34] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[34ページ]RFC4172インターネット繊維チャンネル
Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the
local gateway when it operates in address translation mode. If in
this mode, the gateway SHALL copy this parameter from the Remote
N_PORT descriptor. Otherwise, it is not filled in.
リモートN_PORTアリア--アドレス変換モードで作動するとき、アリアは地方のゲートウェイのそばで_PORTをリモートNに割り当てました。 ゲートウェイSHALLがこのモードでRemote N_PORT記述子からのこのパラメタをコピーするなら。 さもなければ、それは記入されません。
5.2.2.3. Responding to a CBIND Request
5.2.2.3. CBIND要求に応じます。
The gateway receiving a CBIND request SHALL respond as follows:
CBIND要求SHALLが以下の通り反応させるゲートウェイ受信:
a) If the receiver has a duplicate iFCP session in the OPEN PENDING
state, then the receiving gateway SHALL compare the Source N_PORT
Name in the incoming CBIND payload with the Destination N_PORT
Name.
a) 受信機がOPEN PENDING状態で写しiFCPセッションを過すなら、受信ゲートウェイSHALLは入って来るCBINDペイロードでSource N_PORT NameをDestination N_PORT Nameと比較します。
b) If the Source N_PORT Name is greater, the receiver SHALL issue a
CBIND response of "Success" and SHALL place the session in the
OPEN state.
b) Source N_PORT Nameが、より大きいなら、受信機SHALLは「成功」のCBIND応答を発行します、そして、SHALLはオープン状態にセッションを置きます。
c) If the Source N_PORT Name is less, the receiver shall issue a
CBIND RESPONSE of Failed - N_PORT session already exists. The
state of the receiver-initiated iFCP session SHALL BE unchanged.
c) Source N_PORT Nameが、より少ないなら、受信機はFailedのCBIND RESPONSEを発行するものとします--N_PORTセッションは既に存在しています。 受信機で開始しているiFCPセッションSHALL BEの州、変わりがありません。
d) If there is no duplicate iFCP session in the OPEN PENDING state,
the receiving gateway SHALL issue a CBIND response. If a status
of Success is returned, the receiving gateway SHALL create the
iFCP session and place it in the OPEN state. An iFCP session
descriptor SHALL be created as described in Section 5.2.2.2.
d) 写しiFCPセッションが全くOPEN PENDING状態になければ、受信ゲートウェイSHALLはCBIND応答を発行します。 Successの状態が返されるなら、受信ゲートウェイSHALLはiFCPセッションを作成して、オープン状態にそれを置きます。 iFCPセッション記述子SHALL、セクション5.2.2で.2に説明されるように、作成されてください。
e) If a remote N_PORT descriptor does not exist, one SHALL be created
and filled in as described in Section 5.2.2.1.
e) 1SHALL、リモートN_PORT記述子がそうしないなら、存在してください。セクション5.2.2で.1について説明するとき、作成されて、記入されます。
5.2.2.4. Monitoring iFCP Connectivity
5.2.2.4. モニターしているiFCPの接続性
During extended periods of inactivity, an iFCP session may be terminated due to a hardware failure within the gateway or through loss of TCP/IP connectivity. The latter may occur when the session traverses a stateful intermediate device, such as a NA(P)T box or firewall, that detects and purges connections it believes are unused.
不活発の長期間の間、iFCPセッションはゲートウェイかTCP/IPの接続性の損失によるハードウェアの故障のため終えられるかもしれません。 セッションがそれが未使用であると信じている接続を検出して、掃除するNA(P)T箱かファイアウォールなどのstateful中間的装置を横断するとき、後者は起こるかもしれません。
To test session liveness, expedite the detection of connectivity failures, and avoid spontaneous connection termination, an iFCP gateway may maintain a low level of session activity and monitor the session by requesting that the remote gateway periodically transmit the LTEST message described in Section 6.3. All iFCP gateways SHALL support liveness testing as described in this specification.
iFCPゲートウェイは、セッション活性をテストして、接続性失敗の検出を速めて、自然発生的な接続終了を避けるために、低レベルのセッション活動を維持して、リモートゲートウェイが定期的にセクション6.3で説明されたLTESTメッセージを送るよう要求することによって、セッションをモニターするかもしれません。 すべてのiFCPゲートウェイSHALLがこの仕様で説明されるように活性テストを支持します。
Monia, et al. Standards Track [Page 35] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[35ページ]RFC4172インターネット繊維チャンネル
A gateway requests the LTEST heartbeat by specifying a non-zero value for the LIVENESS TEST INTERVAL in the CBIND request or response message as described in Section 6.1. If both gateways seek to monitor liveness, each must set the LIVENESS TEST INTERVAL in the CBIND request or response.
ゲートウェイは、セクション6.1で説明されるようにCBIND要求か応答メッセージで非ゼロ値をLIVENESS TEST INTERVALに指定することによって、LTEST鼓動を要求します。 両方のゲートウェイが活性をモニターしようとするなら、それぞれがCBIND要求か応答にLIVENESS TEST INTERVALをはめ込まなければなりません。
Upon receiving such a request, the gateway providing the heartbeat SHALL transmit LTEST messages at the specified interval. The first message SHALL be sent as soon as the iFCP session enters the OPEN state. LTEST messages SHALL NOT be sent when the iFCP session is not in the OPEN state.
鼓動SHALLはそのような要求、ゲートウェイ提供を受けると指定された間隔で、LTESTメッセージを送ります。 1番目はSHALLを通信させます。iFCPセッションがオープン状態に入るとすぐに、送ります。 LTESTはSHALL NOTを通信させます。iFCPセッションが送らないとき、オープン状態で送ってください。
An iFCP session SHALL be terminated as described in Section 5.2.3 if:
iFCPセッションSHALL、セクション5.2.3で説明されるように終えられてください、:
a) the contents of the LTEST message are incorrect, or
またはa) LTESTメッセージの内容が不正確である。
b) an LTEST message is not received within twice the specified
interval or the iFCP session has been quiescent for longer than
twice the specified interval.
b) LTESTメッセージが指定された間隔の2倍中に受け取られないか、またはiFCPセッションは指定された間隔の2倍より長い間、静かです。
The gateway to receive the LTEST message SHALL measure the interval for the first expected LTEST message from when the session is placed in the OPEN state. Thereafter, the interval SHALL be measured relative to the last LTEST message received.
セッションがオープン状態に置かれる時からSHALLが最初の予想されたLTESTメッセージのために間隔を測定するというLTESTメッセージを受け取るゲートウェイ。 その後、間隔SHALL、LTESTメッセージが受けた最終に比例して、測定されてください。
To maximize liveness test coverage, LTEST messages SHOULD flow through all the gateway components used to enter and retrieve fibre channel frames from the IP network, including the mechanisms for encapsulating and de-encapsulating fibre channel frames.
すべてのゲートウェイの部品を通るLTESTメッセージSHOULD流動は、活性テスト適用範囲を最大にするために、IPネットワークから繊維チャンネルフレームに入って、以前はよく検索していました、要約と反-要約繊維チャンネルフレームへのメカニズムを含んでいて。
In addition to monitoring a session, information in the LTEST message encapsulation header may also be used to compute an estimate of network propagation delay, as described in Section 8.2.1. However, the propagation delay limit SHALL NOT be enforced for LTEST traffic.
また、セッションをモニターすることに加えて、LTESTメッセージカプセル化ヘッダーの情報はネットワーク伝播遅延の見積りを計算するのに使用されるかもしれません、セクション8.2.1で説明されるように。 しかしながら、伝播は限界SHALL NOTを遅らせます。LTEST交通に実施されます。
5.2.2.5. Use of TCP Features and Settings
5.2.2.5. TCPの特徴と設定の使用
This section describes ground rules for the use of TCP features in an iFCP session. The core TCP protocol is defined in [RFC793]. TCP implementation requirements and guidelines are specified in [RFC1122].
このセクションはiFCPセッションにおけるTCPの特徴の使用のために基本規則について説明します。 コアTCPプロトコルは[RFC793]で定義されます。 TCP実現要件とガイドラインは[RFC1122]で指定されます。
Monia, et al. Standards Track [Page 36] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[36ページ]RFC4172インターネット繊維チャンネル
+-----------+------------+--------------+------------+------------+ | Feature | Applicable | RFC | Peer-Wise | Requirement| | | RFCs | Status | Agreement | Level | | | | | Required? | | +===========+============+==============+============+============+ | Keep Alive| [RFC1122] | None | No | Should not | | |(discussion)| | | use | +-----------+------------+--------------+------------+------------+ | Tiny | [RFC896] | Standard | No | Should not | | Segment | | | | use | | Avoidance | | | | | | (Nagle) | | | | | +-----------+------------+--------------+------------+------------+ | Window | [RFC1323] | Proposed | No | Should use | | Scale | | Standard | | | +-----------+------------+--------------+------------+------------+ | Wrapped | [RFC1323] | Proposed | No | SHOULD use | | Sequence | | Standard | | | | Protection| | | | | | (PAWS) | | | | | +-----------+------------+--------------+------------+------------+
+-----------+------------+--------------+------------+------------+ | 特徴| 適切| RFC| 的にじっと見てください。| 要件| | | RFCs| 状態| 協定| レベル| | | | | 必要ですか? | | +===========+============+==============+============+============+ | 生きているままでいてください。| [RFC1122]| なし| いいえ| should| | |(議論)| | | 使用| +-----------+------------+--------------+------------+------------+ | 小さい| [RFC896]| 規格| いいえ| should| | セグメント| | | | 使用| | 回避| | | | | | (ネーグル) | | | | | +-----------+------------+--------------+------------+------------+ | 窓| [RFC1323]| 提案されます。| いいえ| 使用するべきです。| | スケール| | 規格| | | +-----------+------------+--------------+------------+------------+ | 包装されます。| [RFC1323]| 提案されます。| いいえ| SHOULD使用| | 系列| | 規格| | | | 保護| | | | | | (足) | | | | | +-----------+------------+--------------+------------+------------+
Table 1. Usage of Optional TCP Features
1を見送ってください。 任意のTCPの特徴の用法
The following sections describe these options in greater detail.
以下のセクションは詳細によりすばらしいこれらのオプションについて説明します。
5.2.2.5.1. Keep Alive
5.2.2.5.1. 生きているままでいてください。
Keep Alive speeds the detection and cleanup of dysfunctional TCP connections by sending traffic when a connection would otherwise be idle. The issues are discussed in [RFC1122].
Alive速度が機能不全のTCP接続の検出とクリーンアップであることをそうでなければ、接続が無駄であるだろうというときに交通を送ることによって、保ってください。 [RFC1122]で問題について議論します。
In order to test the device more comprehensively, fibre channel applications, such as storage, may implement an equivalent keep alive function at the FC-4 level. Alternatively, periodic liveness test messages may be issued as described in Section 5.2.2.4. Because of these more comprehensive end-to-end mechanisms and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented.
より包括的に、繊維チャンネルアプリケーションが格納などのように実行するかもしれない装置を検査するために、同等物はFC-4レベルにおける機能を生かします。 あるいはまた、セクション5.2.2で.4に説明されるように周期的な活性テストメッセージを発行するかもしれません。 より包括的なメカニズムと問題が[RFC1122]で説明して、生きているままであるこれらの終わりから終わりのために、トランスポート層を実行するべきではありません。
5.2.2.5.2. 'Tiny' Segment Avoidance (Nagle)
5.2.2.5.2. '小さい'セグメント回避(ネーグル)
The Nagle algorithm described in [RFC896] is designed to avoid the overhead of small segments by delaying transmission in order to agglomerate transfer requests into a large segment. In iFCP, such small transfers often contain I/O requests. The transmission delay of the Nagle algorithm may decrease I/O throughput. Therefore, the Nagle algorithm should not be used.
[RFC896]で説明されたネーグルアルゴリズムは、大きいセグメントに転送要求を塊にするためにトランスミッションを遅らせることによって小さいセグメントのオーバーヘッドを避けるように設計されています。 iFCPでは、そのような小さい転送はしばしば入出力要求を含んでいます。 ネーグルアルゴリズムのトランスミッション遅れは入出力スループットを減少させるかもしれません。 したがって、ネーグルアルゴリズムを使用するべきではありません。
Monia, et al. Standards Track [Page 37] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[37ページ]RFC4172インターネット繊維チャンネル
5.2.2.5.3. Window Scale
5.2.2.5.3. 窓のスケール
Window scaling, as specified in [RFC1323], allows full use of links with large bandwidth - delay products and should be supported by an iFCP implementation.
窓は、[RFC1323]で指定されるように比例して、大きい帯域幅とのリンクの完全利用--製品を遅らせるのを許容して、iFCP実現でサポートされるべきです。
5.2.2.5.4. Wrapped Sequence Protection (PAWS)
5.2.2.5.4. 包装された系列保護(足)
TCP segments are identified with 32-bit sequence numbers. In networks with large bandwidth - delay products, it is possible for more than one TCP segment with the same sequence number to be in flight. In iFCP, receipt of such a sequence out of order may cause out-of-order frame delivery or data corruption. Consequently, this feature SHOULD be supported as described in [RFC1323].
TCPセグメントは32ビットの一連番号と同一視されています。 中、大きい帯域幅に伴うネットワーク--遅れ製品、同じ一連番号がある1つ以上のTCPセグメントが飛行であるのは、可能です。 iFCPでは、あれほどa系列故障することの領収書は不適切なフレーム配送かデータの汚染を引き起こすかもしれません。 その結果、これはSHOULDを特集します。[RFC1323]で説明されるように、支持されます。
Monia, et al. Standards Track [Page 38] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[38ページ]RFC4172インターネット繊維チャンネル
5.2.3. Terminating iFCP Sessions
5.2.3. iFCPセッションを終えます。
iFCP sessions SHALL be terminated in response to one of the events in Table 2:
iFCPセッションSHALL、Table2の出来事の1つに対応して、終えられてください:
+-------------------------------------------+---------------------+ | Event | iFCP Sessions | | | to Terminate | +===========================================+=====================+ | PLOGI terminated with LS_RJT response | Peer N_PORT | +-------------------------------------------+---------------------+ | State change notification indicating | All iFCP Sessions | | N_PORT removal or reconfiguration. | from the | | | reconfigured N_PORT | +-------------------------------------------+---------------------+ | LOGO ACC response from peer N_PORT | Peer N_PORT | +-------------------------------------------+---------------------+ | ACC response to LOGO ELS sent to F_PORT | All iFCP sessions | | server (D_ID = 0xFF-FF-FE) (fabric | from the originating| | logout) | N_PORT | +-------------------------------------------+---------------------+ | Implicit N_PORT LOGO as defined in | All iFCP sessions | | [FC-FS] | from the N_PORT | | | logged out | +-------------------------------------------+---------------------+ | LTEST Message Error (see Section 5.2.2.4) | Peer N_PORT | +-------------------------------------------+---------------------+ | Non fatal encapsulation error as | Peer N_PORT | | specified in Section 5.3.3 | | +-------------------------------------------+---------------------+ | Failure of the TCP connection associated | Peer N_PORT | | with the iFCP session | | +-------------------------------------------+---------------------+ | Receipt of an UNBIND session control | Peer N_PORT | | message | | +-------------------------------------------+---------------------+ | Gateway enters the Unsynchronized state | All iFCP sessions | | (see Section 8.2.1) | | +-------------------------------------------+---------------------+ | Gateway detects incorrect address mode | All iFCP sessions | | to peer gateway(see Section 4.6.2) | with peer gateway | +-------------------------------------------+---------------------+
+-------------------------------------------+---------------------+ | 出来事| iFCPセッション| | | 終わるために| +===========================================+=====================+ | LS_RJT応答で終えられたPLOGI| 同輩N_ポート| +-------------------------------------------+---------------------+ | 州の変更届出書表示| すべてのiFCPセッション| | N_PORT取り外しか再構成。 | the| | | 再構成されたN_PORT| +-------------------------------------------+---------------------+ | 同輩N_PORTからのLOGO ACC応答| 同輩N_ポート| +-------------------------------------------+---------------------+ | F_PORTに送られたLOGO ELSへのACC応答| すべてのiFCPセッション| | サーバ(D_IDは0xFF-FF-FEと等しい)、(織物| 由来から|、|、ログアウト、)| N_ポート| +-------------------------------------------+---------------------+ | 中で定義される内在しているN_PORT LOGO| すべてのiFCPセッション| | [FC-FS]| N_ポートから| | | ログアウトされます。| +-------------------------------------------+---------------------+ | LTESTメッセージ誤り、(.4は、)5.2に.2を区分するのを見ます。| 同輩N_ポート| +-------------------------------------------+---------------------+ | 非致命的なカプセル化誤り| 同輩N_ポート| | セクション5.3.3では、指定されます。| | +-------------------------------------------+---------------------+ | 接続が関連づけたTCPの失敗| 同輩N_ポート| | iFCPセッションで| | +-------------------------------------------+---------------------+ | UNBINDセッション制御の領収書| 同輩N_ポート| | メッセージ| | +-------------------------------------------+---------------------+ | ゲートウェイはUnsynchronized状態に入ります。| すべてのiFCPセッション| | (セクション8.2.1を見ます) | | +-------------------------------------------+---------------------+ | ゲートウェイは不正確なアドレス・モードを検出します。| すべてのiFCPセッション| | 同輩ゲートウェイ(セクション4.6.2を見る)に| 同輩ゲートウェイで| +-------------------------------------------+---------------------+
Table 2. Session Termination Events
2を見送ってください。 セッション終了出来事
Monia, et al. Standards Track [Page 39] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[39ページ]RFC4172インターネット繊維チャンネル
If a session is being terminated due to an incorrect address mode with the peer gateway, the TCP connection SHALL be aborted by means of a connection reset (RST) without performing an UNBIND. Otherwise, if the TCP connection is still open following the event, the gateway SHALL shut down the connection as follows:
セッションが終えられているなら、同輩ゲートウェイ、TCP接続SHALLがある不正確なアドレス・モードはUNBINDを実行することのない接続リセット(RST)によって中止されますか? さもなければ、出来事に続いて、TCP接続がまだオープンであるなら、ゲートウェイSHALLは以下の接続を止めます:
a) Stop sending fibre channel frames over the TCP connection.
a) 繊維チャンネルフレームをTCP接続の上に送るのを止めてください。
b) Discard all incoming traffic, except for an UNBIND session control
message.
b) UNBINDセッション制御メッセージ以外のすべての入って来る交通を捨ててください。
c) If an UNBIND message is received at any time, return a response in
accordance with Section 6.2.
c) いつでもUNBINDメッセージを受け取るなら、セクション6.2に応じて、応答を返してください。
d) If session termination was not triggered by an UNBIND message,
issue the UNBIND session control message, as described in Section
6.2.
d) セッション終了がUNBINDメッセージによって引き起こされなかったなら、UNBINDセッション制御メッセージを発行してください、セクション6.2で説明されるように。
e) If the UNBIND message completes with a status of Success, the TCP
connection MAY remain open at the discretion of either gateway and
may be kept in a pool of unbound connections in order to speed up
the creation of a new iFCP session.
e) UNBINDメッセージがSuccess、TCPの状態でどちらかのゲートウェイの裁量で開いている接続5月の残りを完成して、疾走するために無限の接続のプールの中に保たれるかもしれないなら、新しいiFCPセッションの創造を上げてください。
If the UNBIND fails for any reason, the TCP connection MUST be
terminated. In this case, the connection SHOULD be aborted with a
connection reset (RST).
UNBINDがどんな理由でも失敗するなら、TCP接続を終えなければなりません。 この場合接続SHOULD、接続リセット(RST)と共に中止されてください。
For each terminated session, the session descriptor SHALL be deleted. If a session was terminated by an event other than an implicit LOGO or a LOGO ACC response, the gateway shall issue a LOGO to the locally attached N_PORT on behalf of the remote N_PORT.
それぞれがセッション、セッション記述子SHALLを終えました。削除されます。 セッションが内在しているLOGOかLOGO ACC応答以外の出来事によって終えられたなら、ゲートウェイはリモートN_PORTを代表して局所的に添付のN_PORTにLOGOを発行するものとします。
To recover resources, either gateway may spontaneously close an unbound TCP connection at any time. If a gateway terminates a connection with a TCP close operation, the peer gateway MUST respond by executing a TCP close.
リソースを回復するために、どちらのゲートウェイもいつでも、自然に無限のTCP接続を終えるかもしれません。 ゲートウェイがTCPの厳密な操作との関係を終えるなら、同輩ゲートウェイは、近くでTCPを実行することによって、応じなければなりません。
5.3. Fibre Channel Frame Encapsulation
5.3. 繊維チャンネルフレームカプセル化
This section describes the iFCP encapsulation of fibre channel frames. The encapsulation complies with the common encapsulation format defined in [ENCAP], portions of which are included here for convenience.
このセクションは繊維チャンネルフレームのiFCPカプセル化について説明します。 カプセル化はそれの部分が便宜のためにここに含まれている[ENCAP]で定義された一般的なカプセル化書式に従います。
Monia, et al. Standards Track [Page 40] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[40ページ]RFC4172インターネット繊維チャンネル
The format of an encapsulated frame is shown below:
要約のフレームの書式は以下に示されます:
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
+--------------------+ | ヘッダー| +--------------------+-----+ | SOF| f| +--------------------+ F r| | FCフレーム内容| C a| +--------------------+ m| | EOF| e| +--------------------+-----+
Figure 12. Encapsulation Format
図12。 カプセル化形式
The encapsulation consists of a 7-word header, an SOF delimiter word, the FC frame (including the fibre channel CRC), and an EOF delimiter word. The header and delimiter formats are described in the following sections.
カプセル化は7単語のヘッダー、SOFデリミタ単語、FCフレーム(繊維チャンネルCRCを含んでいる)、およびEOFデリミタ単語から成ります。 ヘッダーとデリミタ形式は以下のセクションで説明されます。
5.3.1. Encapsulation Header Format
5.3.1. カプセル化ヘッダー形式
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| Reserved (must be zero) |
+---------------+---------------+---------------+---------------+
2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
W|------------------------------ビット------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+---------------+---------------+ 0| プロトコル#| バージョン| -プロトコル#| -バージョン| +---------------+---------------+---------------+---------------+ 1| 予約されます(ゼロでなければなりません)。| +---------------+---------------+---------------+---------------+ 2| _LS_コマンドACC| iFCP旗| SOF| EOF| +-----------+---+---------------+-----------+---+---------------+ 3| 旗| フレームの長さ| -旗| -フレームの長さ| +-----------+-------------------+-----------+-------------------+ 4| タイムスタンプ[整数]| +---------------------------------------------------------------+ 5| タイムスタンプ[断片]| +---------------------------------------------------------------+ 6| CRC| +---------------------------------------------------------------+
Figure 13. Encapsulation Header Format
図13。 カプセル化ヘッダー形式
Common Encapsulation Fields:
一般的なカプセル化分野:
Protocol# IANA-assigned protocol number identifying the
protocol using the encapsulation. For iFCP, the
value assigned by [ENCAP] is 2.
カプセル化を使用することでプロトコルを特定する#IANAによって割り当てられたプロトコル番号について議定書の中で述べてください。 iFCPに関しては、[ENCAP]によって割り当てられた値は2です。
Monia, et al. Standards Track [Page 41] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[41ページ]RFC4172インターネット繊維チャンネル
Version Encapsulation version, as specified in [ENCAP].
[ENCAP]で指定されるようなバージョンEncapsulationバージョン。
-Protocol# Ones complement of the Protocol#.
-Onesが補足となるプロトコル#の#、について議定書の中で述べてください。
-Version Ones complement of the version.
-Onesが補足となるバージョンのバージョン。
Flags Encapsulation flags (see 5.3.1.1).
見てください。Encapsulationが旗を揚げさせる旗、(5.3 .1 .1)。
Frame Length Contains the length of the entire FC
Encapsulated frame, including the FC
Encapsulation Header and the FC frame (including
SOF and EOF words) in units of 32-bit words.
全体のFC Encapsulatedフレームの長さのLength Containsを縁どってください、ユニットの32ビットの単語にFC Encapsulation HeaderとFCフレーム(SOFとEOF単語を含んでいる)を含んでいて。
-Flags Ones complement of the Flags field.
-Onesが補足となるFlags分野の旗。
-Frame Length Ones complement of the Frame Length field.
-Frame Length分野のLength Ones補数を縁どってください。
Time Stamp [integer] Integer component of the frame time stamp, as
specified in [ENCAP].
[ENCAP]で指定されるようなフレーム時間スタンプの時間Stamp[整数]整数成分。
Time Stamp Fractional component of the time stamp, [fraction] as specified in [ENCAP].
タイムスタンプの時間Stamp Fractionalの部品、[ENCAP]の指定されるとしての[断片。]
CRC Header CRC. MUST be valid for iFCP.
CRCヘッダーCRC。 iFCPに有効でなければならなくなってください。
The time stamp fields are used to enforce the limit on the lifetime of a fibre channel frame as described in Section 8.2.1.
タイムスタンプ分野は、セクション8.2.1で説明されるように繊維チャンネルフレームの生涯における限界を実施するのに使用されます。
iFCP-Specific Fields:
iFCP特有のフィールズ:
LS_COMMAND_ACC For a special link service ACC response to be
processed by iFCP, the LS_COMMAND_ACC field
SHALL contain a copy of bits 0 through 7 of the
LS_COMMAND to which the ACC applies. Otherwise,
the LS_COMMAND_ACC field SHALL be set to zero.
LS_COMMAND_ACC ForはiFCP(SHALLがLS_COMMANDのビット0〜7のコピーを含むACCが適用するLS_COMMAND_ACC分野)によって処理されるべき特別なリンクサービスACC応答です。 さもなければ、LS_COMMAND_ACCはSHALLをさばきます。ゼロに、用意ができています。
iFCP Flags iFCP-specific flags (see below).
iFCP Flags iFCP特有の旗(以下を見ます)。
SOF Copy of the SOF delimiter encoding (see Section
5.3.2).
SOFデリミタコード化(セクション5.3.2を見る)のSOF Copy。
EOF Copy of the EOF delimiter encoding (see Section
5.3.2).
EOFデリミタコード化(セクション5.3.2を見る)のEOF Copy。
Monia, et al. Standards Track [Page 42] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[42ページ]RFC4172インターネット繊維チャンネル
The iFCP flags word has the following format:
旗が言い表すiFCPは以下の形式を持っています:
|------------------------Bit----------------------------|
| |
| 8 9 10 11 12 13 14 15 |
+------+------+------+------+------+------+------+------+
| Reserved | SES | TRP | SPC |
+------+------+------+------+------+------+------+------+
|------------------------ビット----------------------------| | | | 8 9 10 11 12 13 14 15 | +------+------+------+------+------+------+------+------+ | 予約されます。| SES| TRP| SPC| +------+------+------+------+------+------+------+------+
Figure 14. iFCP Flags Word
iFCP旗が言い表す図14
iFCP Flags:
iFCPは弛みます:
SES 1 = Session control frame (TRP and SPC MUST be 0)
SES1はSession制御フレームと等しいです。(TRPとSPC MUST、0になってください)。
TRP 1 = Address transparent mode enabled
TRP1は透過モードが可能にしたアドレスと等しいです。
0 = Address translation mode enabled
0 モードが可能にした=アドレス変換
SPC 1 = Frame is part of a link service message requiring
special processing by iFCP prior to forwarding to the
destination N_PORT.
SPC1=フレームはN_PORTを目的地に送る前にiFCPによる特別な処理を必要とするリンクサービスメッセージの一部です。
5.3.1.1. Common Encapsulation Flags
5.3.1.1. 一般的なカプセル化旗
The iFCP usage of the common encapsulation flags defined in [ENCAP] is shown in Figure 15:
[ENCAP]で定義された一般的なカプセル化旗のiFCP使用法は図15に示されます:
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
|------------------------ビット--------------------------| | | | 0 1 2 3 4 5 | +--------------------------------------------+--------+ | 予約されます。| CRCV| +--------------------------------------------+--------+
Figure 15. iFCP Common Encapsulation Flags
図15 iFCPの一般的なカプセル化旗
For iFCP, the CRC field MUST be valid, and CRCV MUST be set to one.
iFCPに関しては、CRC分野が有効であるに違いない、CRCV MUST、1つに設定されてください。
Monia, et al. Standards Track [Page 43] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[43ページ]RFC4172インターネット繊維チャンネル
5.3.2. SOF and EOF Delimiter Fields
5.3.2. SOFとEOFデリミタ分野
The format of the delimiter fields is shown below.
デリミタ分野の書式は以下に示されます。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
W|------------------------------ビット------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3| d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+---------------+---------------+ 0| SOF| SOF| -SOF| -SOF| +---------------+---------------+---------------+---------------+ 1| | +----- FCフレーム内容-----+ | | +---------------+---------------+---------------+---------------+ n| EOF| EOF| -EOF| -EOF| +---------------+---------------+---------------+---------------+
Figure 16. FC Frame Encapsulation Format
図16。 FCフレームカプセル化形式
SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following subset of the SOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 3. The authoritative encodings should be obtained from [ENCAP].
SOF(Word0によるビット0-7とビット8-15): iFCPは[ENCAP]で指定されたSOF分野の以下の部分集合を使用します。 便利において、これらはTable3で再生します。 [ENCAP]から正式のencodingsを入手するべきです。
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
+-------+----------+ | FC| | | SOF| SOFコード| +-------+----------+ | SOFi2| 0x2D| | SOFn2| 0×35| | SOFi3| 0x2E| | SOFn3| 0×36| +-------+----------+
Table 3. Translation of FC SOF Values to SOF Field Contents
3を見送ってください。 SOF分野コンテンツへのFC SOF値に関する翻訳
-SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the ones complement the value in the SOF fields.
-SOF(Word0によるビット16-23と24-31): -SOF分野はSOFの値がさばくもの補数を含んでいます。
EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset of EOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 4. The authoritative encodings should be obtained from [ENCAP].
EOF(単語nによるビット0-7と8-15): iFCPは[ENCAP]で指定されたEOF分野の以下の部分集合を使用します。 便利において、これらはTable4で再生します。 [ENCAP]から正式のencodingsを入手するべきです。
Monia, et al. Standards Track [Page 44] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[44ページ]RFC4172インターネット繊維チャンネル
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
+-------+----------+ | FC| | | EOF| EOFコード| +-------+----------+ | EOFn| 0×41| | EOFt| 0×42| +-------+----------+
Table 4. Translation of FC EOF Values to EOF Field Contents
4を見送ってください。 EOF分野コンテンツへのFC EOF値に関する翻訳
-EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the ones complement the value in the EOF fields.
-EOF(単語nによるビット16-23と24-31): -EOF分野はEOFの値がさばくもの補数を含んでいます。
iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields.
iFCP実現SHALLはSOFとEOFデリミタコードのコピーを適切なヘッダーフィールドに置きます。
5.3.3. Frame Encapsulation
5.3.3. フレームカプセル化
A fibre channel Frame to be encapsulated MUST first be validated as described in [FC-FS]. Any frames received from a locally attached fibre channel device that do not pass the validity tests in [FC-FS] SHALL be discarded by the gateway.
最初に、[FC-FS]で説明されるように要約されるべき繊維チャンネルFrameを有効にしなければなりません。 どんなフレームも捨てられて、ゲートウェイで[FC-FS]SHALLでの正当性テストに合格しない局所的に添付の繊維チャンネル装置から受信されました。
If the frame is a PLOGI ELS, the creation of an iFCP session, as described in Section 7.3.1.7, may precede encapsulation. Once the session has been created, frame encapsulation SHALL proceed as follows.
フレームがPLOGI ELSであるなら、iFCPセッションの創造は、セクション7.3.1で.7について説明するので、カプセル化に先行するかもしれません。 セッションがいったん作成されると、フレームカプセル化SHALLは以下の通り続きます。
The S_ID and D_ID fields in the frame header SHALL be referenced to look up the iFCP session descriptor (see Section 5.2.2.2). If no iFCP session descriptor exists, the frame SHALL be discarded.
セクション5.2を見てください。参照をつけられて、IDがフレームヘッダーSHALLでさばくS_IDとD_がiFCPセッション記述子を外観に上げる、(.2 .2)。 記述子はiFCPセッションでないなら存在していて、フレームはSHALLです。捨てられます。
Frame types submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 3 and an EOF delimiter from Table 4. Other valid frame types MUST be processed internally by the gateway as specified in the appropriate fibre channel specification.
カプセル化のために提出して、IPネットワークでSHALLを進めるフレームタイプがTable3のSOFデリミタとTable4からのEOFデリミタの1つを持っています。 指定されるとしての適切な繊維チャンネル仕様によるゲートウェイで内部的に他の有効なフレームタイプを処理しなければなりません。
If operating in address translation mode and processing a special link service message requiring the inclusion of supplemental data, the gateway SHALL format the frame payload and add the supplemental information specified in Section 7.1. The gateway SHALL then calculate a new FC CRC on the reformatted frame.
アドレス変換モードで作動して、補足のデータの包含を必要とする特別なリンクサービスメッセージを処理するなら、ゲートウェイSHALLは、フレームペイロードをフォーマットして、補足的情報がセクション7.1で指定したと言い足します。 そして、ゲートウェイSHALLは再フォーマットされたフレームの上に新しいFC CRCについて計算します。
Otherwise, the frame contents SHALL NOT be modified and the gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC.
さもなければ、FC CRCについて再計算しないで、フレームコンテンツSHALL NOTは変更されていて5月が要約するゲートウェイであり、フレームイメージを送ります。
Monia, et al. Standards Track [Page 45] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[45ページ]RFC4172インターネット繊維チャンネル
The frame originator MUST then create and fill in the header and the SOF and EOF delimiter words, as specified in Sections 5.3.1 and 5.3.2.
次に、フレーム創始者は、ヘッダー、SOF、およびEOFデリミタ単語を創造して、記入しなければなりません、セクション5.3.1と5.3で.2に指定されるように
5.3.4. Frame De-encapsulation
5.3.4. フレーム反-カプセル化
The receiving gateway SHALL perform de-encapsulation as follows:
受信ゲートウェイSHALLは以下の反-カプセル化を実行します:
Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the header CRC is valid, the receiving gateway SHALL check the iFCP flags field. If one of the error conditions in Table 5 is detected, the gateway SHALL handle the error as specified in Section 5.2.3.
要約のフレームを受けると、ゲートウェイSHALLはヘッダーCRCをチェックします。 ヘッダーCRCが有効であるなら、受信ゲートウェイSHALLは旗がさばくiFCPをチェックします。 Table5のエラー条件の1つが検出されるなら、ゲートウェイSHALLはセクション5.2.3における指定されるとしての誤りを扱います。
+------------------------------+-------------------------+
| Condition | Error Type |
+==============================+=========================+
| Header CRC Invalid | Encapsulation error |
+------------------------------+-------------------------+
| SES = 1, TRP or SPC not 0 | Encapsulation error |
+------------------------------+-------------------------+
| SES = 0, TRP set incorrectly | Incorrect address mode |
+------------------------------+-------------------------+
+------------------------------+-------------------------+ | 状態| 誤りタイプ| +==============================+=========================+ | ヘッダーCRC病人| カプセル化誤り| +------------------------------+-------------------------+ | SESは0ではなく1、TRPまたはSPCと等しいです。| カプセル化誤り| +------------------------------+-------------------------+ | SESは0、不当に用意ができているTRPと等しいです。| 不正確なアドレス・モード| +------------------------------+-------------------------+
Table 5. Encapsulation Header Errors
5を見送ってください。 カプセル化ヘッダー誤り
The receiving gateway SHALL then verify the frame propagation delay as described in Section 8.2.1. If the propagation delay is too long, the frame SHALL be discarded. Otherwise, the gateway SHALL check the SOF and EOF in the encapsulation header. A frame SHALL be discarded if it has an SOF code that is not in Table 3 or an EOF code that is not in Table 4.
そして、受信ゲートウェイSHALLはセクション8.2.1で説明されるようにフレーム伝播遅延について確かめます。 遅れは伝播であるなら長過ぎ、フレームはSHALLです。捨てられます。 さもなければ、ゲートウェイSHALLはカプセル化ヘッダーでSOFとEOFをチェックします。 それにTable3にないSOFコードかTable4にないEOFコードがあるなら捨てられて、AはSHALLを縁どっています。
The gateway SHALL then de-encapsulate the frame as follows:
次に、ゲートウェイSHALLは反-以下のフレームを要約します:
a) Check the FC CRC and discard the frame if the CRC is invalid.
a) FC CRCをチェックしてください、そして、CRCが無効であるなら、フレームを捨ててください。
b) If operating in address translation mode, replace the S_ID field
with the N_PORT alias of the frame originator, and the D_ID with
the N_PORT ID, of the frame recipient. Both parameters SHALL be
obtained from the iFCP session descriptor.
b) アドレス変換モードで作動するなら、S_ID分野をフレーム創始者のN_PORT別名、およびN_PORT IDがあるフレーム受取人のD_IDに取り替えてください。 両方のパラメタSHALL、iFCPセッション記述子から、得てください。
c) If processing a special link service message, replace the frame
with a copy whose payload has been modified as specified in
Section 7.1.
c) 特別なリンクサービスメッセージを処理するなら、フレームをペイロードがセクション7.1で指定されるように変更されたコピーに取り替えてください。
Monia, et al. Standards Track [Page 46] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[46ページ]RFC4172インターネット繊維チャンネル
The de-encapsulated frame SHALL then be forwarded to the N_PORT specified in the D_ID field. If the frame contents have been modified by the receiving gateway, a new FC CRC SHALL be calculated.
反-要約にされるのはSHALLを縁どって、次に、D_ID分野で指定されたN_PORTに送ってください。 フレームコンテンツであるなら受信ゲートウェイ、新しいFC CRC SHALLによって変更されてください、そうした。計算されます。
6. TCP Session Control Messages
6. TCPセッション制御メッセージ
TCP session control messages are used to create and manage an iFCP session as described in Section 5.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer.
TCPセッション制御メッセージは、セクション5.2.2で説明されるようにiFCPセッションを作成して、管理するのに使用されます。 それらは、同輩iFCP Portalsの間で通過されて、iFCP層の中で処理されるだけです。
The message format is based on the fibre channel extended link service message template shown below.
形式が繊維チャンネルに基づいているというメッセージは以下で見せられたリンクサービスメッセージテンプレートを広げました。
Word
0<--Bits-->7 8<---------------Bits------------------------>31
+------------+------------------------------------------------+
0| R_CTL | D_ID [0x00 00 00] |
|[Req = 0x22]| [Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID [0x00 00 00] |
| [0x0] | [Source of extended link service request] |
+------------+------------------------------------------------+
2|TYPE [0x1] | F_CTL [0] |
+------------+------------------+-----------------------------+
3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] |
|[0x0] | | |
+------------+------------------+-----------------------------+
4| OX_ID [0x0000] | RX_ID_[0x0000] |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Session Control Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Session Control Parameters |
.| ( if any ) |
n| |
+=============================================================+
n| Fibre Channel CRC |
+| |
1+=============================================================+
0<--ビット-->7 8<を言い表してください。---------------ビット------------------------>31+------------+------------------------------------------------+ 0| R_CTL| D_ID、[0×00、00 00]| |[Req=0x22]| [Serviceが要求する拡張リンクの目的地]| |[レップ=0×23]| | +------------+------------------------------------------------+ 1| Cs_CTL| S_ID、[0×00、00 00]| | [0×0]| [拡張リンクサービスのリクエストの源]| +------------+------------------------------------------------+ 2|タイプ[0×1]| F_CTL[0]| +------------+------------------+-----------------------------+ 3|SEQ_ID| DF_CTL[0×00]| SEQ_CNT[0×00]| |[0×0]| | | +------------+------------------+-----------------------------+ 4| 雄牛_ID[0×0000]| RX_ID_[0×0000]| +-------------------------------+-----------------------------+ 5| パラメタ| | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_コマンド| | [セッション制御コマンド]| +-------------------------------------------------------------+ 7| | . | 追加セッション管理パラメータ| . | (もしあれば)| n| | +=============================================================+ n| 繊維チャンネルCRC| +| | 1+=============================================================+
Figure 17. Format of Session Control Message
図17。 セッション制御メッセージの形式
Monia, et al. Standards Track [Page 47] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[47ページ]RFC4172インターネット繊維チャンネル
The LS_COMMAND value for the response remains the same as that used for the request.
応答のためのLS_COMMAND値は要求に使用されるそれと同じままで残っています。
The session control frame is terminated with a fibre channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules specified in Section 5.3.
セッション制御フレームは繊維チャンネルCRCで終えられます。 規則に従って、要約されて、反-要約されたフレームSHALLはセクション5.3で指定しました。
The encapsulation header for the link Service frame carrying a session control message SHALL be set as follows:
セットは以下の通りであったならセッション制御メッセージSHALLを運ぶリンクServiceフレームへのカプセル化ヘッダー:
Encapsulation Header Fields:
カプセル化ヘッダーフィールド:
LS_COMMAND_ACC 0
LS_コマンド_ACC0
iFCP Flags SES = 1
iFCP旗のSES=1
TRP = 0
TRP=0
INT = 0
INT=0
SOF code SOFi3 encoding (0x2E)
SOFコードSOFi3コード化(0x2E)
EOF code EOFt encoding (0x42)
EOFコードEOFtコード化(0×42)
The encapsulation time stamp words SHALL be set as described for each message type.
スタンプがSHALLを言い表すカプセル化時代に、それぞれのメッセージタイプのために説明されるように、設定されてください。
The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above.
SOFとEOFデリミタはSOFに基づくセットとEOFが上で指定されたコードであったならSHALLを言い表します。
Monia, et al. Standards Track [Page 48] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[48ページ]RFC4172インターネット繊維チャンネル
Table 6 lists the values assigned to byte 0 of the LS_COMMAND field for iFCP session control messages.
テーブル6はiFCPセッション制御メッセージのためにLS_COMMAND分野のバイト0に割り当てられた値を記載します。
+--------------+-------------------------+----------+-------------+ | LS_COMMAND | Function | Mnemonic | iFCP | | field, byte 0| | | Support | +--------------+-------------------------+----------+-------------+ | 0xE0 | Connection Bind | CBIND | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0xE4 | Unbind Connection | UNBIND | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0xE5 | Test Connection Liveness| LTEST | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0x01-0x7F | Vendor-Specific | | | +--------------+-------------------------+----------+-------------+ | 0x00 | Reserved -- Unassignable| | | +--------------+-------------------------+----------+-------------+ | All other | Reserved | | | | values | | | | +--------------+-------------------------+----------+-------------+
+--------------+-------------------------+----------+-------------+ | LS_コマンド| 機能| ニーモニック| iFCP| | 分野、バイト0| | | サポート| +--------------+-------------------------+----------+-------------+ | 0xE0| 接続ひも| CBIND| 必要です。| +--------------+-------------------------+----------+-------------+ | 0xE4| 接続を解いてください。| 解きます。| 必要です。| +--------------+-------------------------+----------+-------------+ | 0xE5| テスト接続活性| LTEST| 必要です。| +--------------+-------------------------+----------+-------------+ | 0×01 0x7F| 業者特有です。| | | +--------------+-------------------------+----------+-------------+ | 0×00| 予約されます--、Unassignable| | | +--------------+-------------------------+----------+-------------+ | すべて他です。| 予約されます。| | | | 値| | | | +--------------+-------------------------+----------+-------------+
Table 6. Session Control LS_COMMAND Field, Byte 0 Values
6を見送ってください。 セッション制御LS_コマンド欄、バイト0値
Monia, et al. Standards Track [Page 49] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[49ページ]RFC4172インターネット繊維チャンネル
6.1. Connection Bind (CBIND)
6.1. 接続ひも(CBIND)
As described in Section 5.2.2.2, the CBIND message and response are used to bind an N_PORT login to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_PORTs are identified by their worldwide port names. The time stamp words in the encapsulation header SHALL be set to zero in the request and response message frames.
_セクション5.2.2で説明されて、.2、CBINDメッセージ、および応答がそうように、Nを縛るのに使用されて、PORTは特定のTCP接続にログインして、iFCPセッションを確立します。 CBIND要求メッセージ、ソース、および目的地では、N_PORTsが彼らの世界的なポート名によって特定されます。 スタンプがカプセル化ヘッダーにSHALLを言い表すとき、要求と応答メッセージでフレームのゼロを合わせるように設定されてください。
The following shows the format of the CBIND request.
以下はCBIND要求の書式を示しています。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+ | Word| バイト0| バイト1| バイト2| バイト3| +------+------------+------------+-----------+----------+ | 0 | Cmdは0xE0と等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | 活性テスト間隔| Addrモード| iFCP Ver| | | (秒) | | | +------+-------------------------+-----------+----------+ | 2 | ユーザインフォメーション| +------+------------+------------+-----------+----------+ | 3 | | +------+ ソースN_ポート名| | 4 | | +------+------------------------------------------------+ | 5 | | +------+ 目的地N_ポート名| | 6 | | +------+------------------------------------------------+
Addr Mode: The addressing mode of the originating
gateway. 0 = Address Translation mode;
1 = Address Transparent mode.
Addrモード: 由来しているゲートウェイのアドレッシング・モード。 0 = Translationモードを記述してください。 1はアドレスTransparentモードと等しいです。
iFCP Ver: iFCP version number. SHALL be set to 1.
iFCP Ver: iFCPバージョン番号。 SHALL、1に設定されてください。
LIVENESS TEST If non-zero, requests that the receiving
INTERVAL: gateway transmit an LTEST message at the
specified interval in seconds. If set to
zero, LTEST messages SHALL NOT be sent.
LIVENESS TEST If非ゼロ、要求、それ、受信INTERVAL: ゲートウェイは秒に指定された間隔で、LTESTメッセージを送ります。 ゼロに合わせるために設定しているLTESTメッセージSHALL NOTであるなら、送ってください。
USER INFO: Contains any data desired by the requestor.
This information MUST be echoed by the
recipient in the CBIND response message.
ユーザインフォメーション: 要請者によって望まれていたどんなデータも含んでいます。 CBIND応答メッセージにおける受取人はこの情報を反映しなければなりません。
SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT
locally attached to the gateway originating
the CBIND request.
ソースN_は名前を移植します: N_PORTのWorldwide Port Name(WWPN)は局所的にCBINDが要求するゲートウェイ由来に付きました。
Monia, et al. Standards Track [Page 50] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[50ページ]RFC4172インターネット繊維チャンネル
DESTINATION N_PORT The Worldwide Port Name (WWPN) of the
NAME: N_PORT locally attached to the gateway
receiving the CBIND request.
目的地N_は名前の世界的なポート名(WWPN)を移植します: N_PORTは局所的にCBINDが要求するゲートウェイ受信に付きました。
The following shows the format of the CBIND response.
以下はCBIND応答の書式を示しています。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
+------+------------+------------+-----------+----------+ | Word| バイト0| バイト1| バイト2| バイト3| +------+------------+------------+-----------+----------+ | 0 | Cmdは0xE0と等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | 活性テスト間隔| Addrモード| iFCP Ver| | | (秒) | | | +------+-------------------------+-----------+----------+ | 2 | ユーザインフォメーション| +------+------------+------------+-----------+----------+ | 3 | | +------+ ソースN_ポート名| | 4 | | +------+------------------------------------------------+ | 5 | | +------+ 目的地N_ポート名| | 6 | | +------+-------------------------+----------------------+ | 7 | 予約されます。| CBIND状態| +------+-------------------------+----------------------+ | 8 | 予約されます。| 接続ハンドル| +------+-------------------------+----------------------+
Total Length = 36
全長=36
Addr Mode: The address translation mode of the
responding gateway. 0 = Address
Translation mode, 1 = Address Transparent
mode.
Addrモード: 応じるゲートウェイのアドレス変換モード。 0 = Translationモードを記述してください、そして、1はアドレスTransparentモードと等しいです。
iFCP Ver: iFCP version number. Shall be set to 1.
iFCP Ver: iFCPバージョン番号。 1に設定されるでしょう。
LIVENESS TEST If non-zero, requests that the gateway
INTERVAL: receiving the CBIND RESPONSE transmit an
LTEST message at the specified interval in
seconds. If zero, LTEST messages SHALL NOT
be sent.
LIVENESS TEST If非ゼロ、要求、それ、ゲートウェイINTERVAL: CBIND RESPONSEを受けて、秒に指定された間隔で、LTESTメッセージを送ってください。 ゼロ、LTESTがSHALL NOTを通信させるなら、送ってください。
USER INFO: Echoes the value received in the USER INFO
field of the CBIND request message.
ユーザインフォメーション: 値がCBINDのUSER INFO分野で受けたエコーズはメッセージを要求します。
Monia, et al. Standards Track [Page 51] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[51ページ]RFC4172インターネット繊維チャンネル
SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of
the N_PORT locally attached to the gateway
issuing the CBIND request.
ソースN_は名前を移植します: 局所的にCBIND要求を出すゲートウェイに取り付けられたN_PORTのWorldwide Port Name(WWPN)を含んでいます。
DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of
NAME: the N_PORT locally attached to the gateway
issuing the CBIND response.
目的地N_港は名前の世界的なポート名(WWPN)を含んでいます: N_PORTは局所的にCBIND応答を発行するゲートウェイに付きました。
CBIND STATUS: Indicates success or failure of the CBIND
request. CBIND values are shown below.
CBIND状態: CBIND要求の成否を示します。 CBIND値は以下に示されます。
CONNECTION HANDLE: Contains a value assigned by the gateway to
identify the connection. The connection
handle is required when the UNBIND
request is issued.
接続ハンドル: ゲートウェイによって割り当てられた、接続を特定した値を含んでいます。 UNBIND要求が出されるとき、接続ハンドルが必要です。
CBIND Status Description ------------ -----------
CBIND状態記述------------ -----------
0 Success
1 - 15 Reserved
16 Failed - Unspecified Reason
17 Failed - No such device
18 Failed - iFCP session already exists
19 Failed - Lack of resources
20 Failed - Incompatible address translation mode
21 Failed - Incorrect protocol version number
22 Failed - Gateway not Synchronized (see Section
8.2)
Others Reserved
19Failedは既に、存在します。成功1--15Reserved16Failed--不特定のReason17Failed--そのような0台の装置でない、18Failed--、iFCPセッション、--財源不足20Failed--両立しないアドレス変換モード21Failed--不正確なプロトコルバージョンは22Failedに付番します--、ゲートウェイSynchronized(セクション8.2を見る)他のものReservedでない
6.2. Unbind Connection (UNBIND)
6.2. 接続を解いてください。(解きます)
UNBIND is used to terminate an iFCP session and disassociate the TCP connection as described in Section 5.2.3.
UNBINDは、セクション5.2.3で説明されるようにiFCPセッションを終えて、TCP接続を分離するのに使用されます。
The UNBIND message is transmitted over the connection that is to be unbound. The time stamp words in the encapsulation header shall be set to zero in the request and response message frames.
UNBINDメッセージは自由であることになっている接続の上に送られます。 カプセル化ヘッダーのタイムスタンプ単語が要求と応答メッセージでフレームのゼロに合うように設定されるものとします。
Monia, et al. Standards Track [Page 52] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[52ページ]RFC4172インターネット繊維チャンネル
The following is the format of the UNBIND request message.
↓これはUNBIND要求メッセージの形式です。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
+------+------------+------------+-----------+----------+ | Word| バイト0| バイト1| バイト2| バイト3| +------+------------+------------+-----------+----------+ | 0 | Cmdは0xE4と等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | ユーザインフォメーション| +------+------------+------------+-----------+----------+ | 2 | 予約されます。| 接続ハンドル| +------+------------+------------+----------------------+ | 3 | 予約されます。| +------+------------+------------+-----------+----------+ | 4 | 予約されます。| +------+------------+------------+-----------+----------+
USER INFO Contains any data desired by the requestor.
This information MUST be echoed by the
recipient in the UNBIND response message.
どんなデータも要請者で望んでいたUSER INFO Contains。 UNBIND応答メッセージにおける受取人はこの情報を反映しなければなりません。
CONNECTION HANDLE: Contains the gateway-assigned value from
the CBIND request.
接続ハンドル: CBIND要求からのゲートウェイ割り当てられた値を含んでいます。
The following shows the format of the UNBIND response message.
以下はUNBIND応答メッセージの書式を示しています。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+-----------+----------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+
+------+------------+------------+-----------+----------+ | Word| バイト0| バイト1| バイト2| バイト3| +------+------------+------------+-----------+----------+ | 0 | Cmdは0xE4と等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | ユーザインフォメーション| +------+------------+------------+-----------+----------+ | 2 | 予約されます。| 接続ハンドル| +------+------------+------------+-----------+----------+ | 3 | 予約されます。| +------+------------+------------+-----------+----------+ | 4 | 予約されます。| +------+------------+------------+-----------+----------+ | 5 | 予約されます。| 状態を解いてください。| +------+------------+------------+-----------+----------+
USER INFO Echoes the value received in the USER INFO
field of the UNBIND request message.
値がUNBINDのUSER INFO分野で受けたUSER INFOエコーズはメッセージを要求します。
CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in
the UNBIND request message.
接続ハンドル: CONNECTION HANDLEがUNBINDで指定したエコーズはメッセージを要求します。
Monia, et al. Standards Track [Page 53] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[53ページ]RFC4172インターネット繊維チャンネル
UNBIND STATUS: Indicates the success or failure of the
UNBIND request as follows:
状態を解いてください: 以下のUNBIND要求の成否を示します:
Unbind Status Description
------------- -----------
状態記述を解いてください。------------- -----------
0 Successful - No other status
1 - 15 Reserved
16 Failed - Unspecified Reason
18 Failed - Connection ID Invalid
Others Reserved
0 --他の状態がありません1--うまくいっている15Reserved16Failed--不特定のReason18Failed--接続ID Invalid Others Reserved
6.3. LTEST -- Test Connection Liveness
6.3. LTEST--テスト接続活性
The LTEST message is sent at the interval specified in the CBIND request or response payload. The LTEST encapsulation time stamp SHALL be set as described in Section 8.2.1 and may be used by the receiver to compute an estimate of propagation delay. However, the propagation delay limit SHALL NOT be enforced.
CBIND要求か応答ペイロードで指定された間隔を置いて、LTESTメッセージを送ります。 LTESTカプセル化タイムスタンプSHALLはセクション8.2.1で説明されるように用意ができて、伝播遅延の見積りに計算する受信機によって使用されるかもしれません。 しかしながら、伝播は限界SHALL NOTを遅らせます。実施されます。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+ | Word| バイト0| バイト1| バイト2| バイト3| +------+------------+------------+-----------+----------+ | 0 | Cmdは0xE5と等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | 活性テスト間隔| 予約されます。| | | (秒) | | +------+-------------------------+----------------------+ | 2 | カウント| +------+------------+------------+-----------+----------+ | 3 | | +------+ ソースN_ポート名| | 4 | | +------+------------------------------------------------+ | 5 | | +------+ 目的地N_ポート名| | 6 | | +------+------------------------------------------------+
LIVENESS TEST Copy of the LIVENESS TEST INTERVAL
INTERVAL: specified in the CBIND request or reply
message.
活性テスト間隔間隔の活性テストコピー: CBIND要求か応答メッセージでは、指定されています。
COUNT: Monotonically increasing value, initialized
to 0 and incremented by one for each
successive LTEST message.
以下を数えてください。 それぞれの連続したLTESTメッセージのために単調に価値を増して、0に初期化されて、1つ増加されます。
Monia, et al. Standards Track [Page 54] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[54ページ]RFC4172インターネット繊維チャンネル
SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME
specified in the CBIND request.
ソースN_は名前を移植します: CBIND要求で指定されたSOURCE N_PORT NAMEのコピーを含んでいます。
DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT NAME: NAME specified in the CBIND request.
コピーのDESTINATION N_PORT Contains DESTINATION N_PORT NAME: NAMEはCBIND要求で指定しました。
7. Fibre Channel Link Services
7. 繊維チャンネルリンクサービス
Link services provide a set of fibre channel functions that allow a port to send control information or request another port to perform a specific control function.
Link services provide a set of fibre channel functions that allow a port to send control information or request another port to perform a specific control function.
There are three types of link services:
There are three types of link services:
a) Basic
a) Basic
b) Extended
b) Extended
c) ULP-specific (FC-4)
c) ULP-specific (FC-4)
Each link service message (request and reply) is carried by a fibre channel sequence and can be segmented into multiple frames.
Each link service message (request and reply) is carried by a fibre channel sequence and can be segmented into multiple frames.
The iFCP layer is responsible for transporting link service messages across the IP network. This includes mapping link service messages appropriately from the domain of the fibre channel transport to that of the IP network. This process may require special processing and the inclusion of supplemental data by the iFCP layer.
The iFCP layer is responsible for transporting link service messages across the IP network. This includes mapping link service messages appropriately from the domain of the fibre channel transport to that of the IP network. This process may require special processing and the inclusion of supplemental data by the iFCP layer.
Each link service MUST be processed according to one of the following rules:
Each link service MUST be processed according to one of the following rules:
a) Pass-through - The link service message and reply MUST be
delivered to the receiving N_PORT by the iFCP protocol layer
without altering the message payload. The link service message
and reply are not processed by the iFCP protocol layer.
a) Pass-through - The link service message and reply MUST be delivered to the receiving N_PORT by the iFCP protocol layer without altering the message payload. The link service message and reply are not processed by the iFCP protocol layer.
b) Special - Applies to a link service reply or request requiring
the intervention of the iFCP layer before forwarding to the
destination N_PORT. Such messages may contain fibre channel
addresses in the payload or may require other special processing.
b) Special - Applies to a link service reply or request requiring the intervention of the iFCP layer before forwarding to the destination N_PORT. Such messages may contain fibre channel addresses in the payload or may require other special processing.
c) Rejected - When issued by a locally attached N_PORT, the specified
link service request MUST be rejected by the iFCP gateway. The
gateway SHALL return an LS_RJT response with a Reason Code of 0x0B
(Command Not Supported), and a Reason Code Explanation of 0x0 (No
Additional Explanation).
c) Rejected - When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the iFCP gateway. The gateway SHALL return an LS_RJT response with a Reason Code of 0x0B (Command Not Supported), and a Reason Code Explanation of 0x0 (No Additional Explanation).
Monia, et al. Standards Track [Page 55] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 55] RFC 4172 Internet Fibre Channel Networking September 2005
This section describes the processing for special link services, including the manner in which supplemental data is added to the message payload.
This section describes the processing for special link services, including the manner in which supplemental data is added to the message payload.
Appendix A enumerates all link services and the iFCP processing policy that applies to each.
Appendix A enumerates all link services and the iFCP processing policy that applies to each.
7.1. Special Link Service Messages
7.1. Special Link Service Messages
Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to:
Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to:
a) service any link service message that requires special handling,
such as a PLOGI, and
a) service any link service message that requires special handling, such as a PLOGI, and
b) service any link service message that has an N_PORT address in the
payload in address translation mode only .
b) service any link service message that has an N_PORT address in the payload in address translation mode only .
Unless the link service description specifies otherwise, support for each special link service is MANDATORY.
Unless the link service description specifies otherwise, support for each special link service is MANDATORY.
Such messages SHALL be transmitted in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services.
Such messages SHALL be transmitted in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services.
Monia, et al. Standards Track [Page 56] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 56] RFC 4172 Internet Fibre Channel Networking September 2005
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x22]|[Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of extended link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| [0x01] | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Extended Link Service Command Code] |
+-------------==----------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Word 0<---Bit-->7 8<-------------------------------------------->31 +------------+------------------------------------------------+ 0| R_CTL | D_ID | |[Req = 0x22]|[Destination of extended link Service request] | |[Rep = 0x23]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID | | | [Source of extended link service request] | +------------+------------------------------------------------+ 2| TYPE | F_CTL | | [0x01] | | +------------+------------------+-----------------------------+ 3| SEQ_ID | DF_CTL | SEQ_CNT | +------------+------------------+-----------------------------+ 4| OX_ID | RX_ID | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [Extended Link Service Command Code] | +-------------==----------------------------------------------+ 7| | .| Additional Service Request Parameters | .| ( if any ) | n| | +-------------------------------------------------------------+
Figure 18. Format of an Extended Link Service Frame
Figure 18. Format of an Extended Link Service Frame
Monia, et al. Standards Track [Page 57] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 57] RFC 4172 Internet Fibre Channel Networking September 2005
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x32]| [Destination of FC-4 link Service request] |
|[Rep = 0x33]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of FC-4 link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| (FC-4 | |
| specific) | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [FC-4 Link Service Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Word 0<---Bit-->7 8<-------------------------------------------->31 +------------+------------------------------------------------+ 0| R_CTL | D_ID | |[Req = 0x32]| [Destination of FC-4 link Service request] | |[Rep = 0x33]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID | | | [Source of FC-4 link service request] | +------------+------------------------------------------------+ 2| TYPE | F_CTL | | (FC-4 | | | specific) | | +------------+------------------+-----------------------------+ 3| SEQ_ID | DF_CTL | SEQ_CNT | +------------+------------------+-----------------------------+ 4| OX_ID | RX_ID | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [FC-4 Link Service Command Code] | +-------------------------------------------------------------+ 7| | .| Additional Service Request Parameters | .| ( if any ) | n| | +-------------------------------------------------------------+
Figure 19. Format of an FC-4 Link Service Frame
Figure 19. Format of an FC-4 Link Service Frame
7.2. Link Services Requiring Payload Address Translation
7.2. Link Services Requiring Payload Address Translation
This section describes the handling for link service frames containing N_PORT addresses in the frame payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required.
This section describes the handling for link service frames containing N_PORT addresses in the frame payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required.
Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gateway's address space. The following rules define the manner in which such supplemental data shall be packaged and referenced.
Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gateway's address space. The following rules define the manner in which such supplemental data shall be packaged and referenced.
Monia, et al. Standards Track [Page 58] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 58] RFC 4172 Internet Fibre Channel Networking September 2005
For an N_PORT address field, the gateway originating the frame MUST set the value in the payload to identify the address translation type as follows:
For an N_PORT address field, the gateway originating the frame MUST set the value in the payload to identify the address translation type as follows:
0x00 00 01 - The gateway receiving the frame from the IP network
MUST replace the contents of the field with the N_PORT alias of
the frame originator. This translation type MUST be used when the
address to be converted is that of the source N_PORT.
0x00 00 01 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT alias of the frame originator. This translation type MUST be used when the address to be converted is that of the source N_PORT.
0x00 00 02 - The gateway receiving the frame from the IP network
MUST replace the contents of the field with the N_PORT ID of the
destination N_PORT. This translation type MUST be used when the
address to be converted is that of the destination N_PORT
0x00 00 02 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT ID of the destination N_PORT. This translation type MUST be used when the address to be converted is that of the destination N_PORT
0x00 00 03 - The gateway receiving the frame from the IP network
MUST reference the specified supplemental data to set the field
contents. The supplemental information is the 64-bit worldwide
identifier of the N_PORT, as set forth in the fibre channel
specification [FC-FS]. If not otherwise part of the link service
payload, this information MUST be appended in accordance with the
applicable link service description. Unless specified otherwise,
this translation type SHALL NOT be used if the address to be
converted corresponds to that of the frame originator or
recipient.
0x00 00 03 - The gateway receiving the frame from the IP network MUST reference the specified supplemental data to set the field contents. The supplemental information is the 64-bit worldwide identifier of the N_PORT, as set forth in the fibre channel specification [FC-FS]. If not otherwise part of the link service payload, this information MUST be appended in accordance with the applicable link service description. Unless specified otherwise, this translation type SHALL NOT be used if the address to be converted corresponds to that of the frame originator or recipient.
Since fibre channel addressing rules prohibit the assignment of fabric addresses with a domain ID of 0, the above codes will never correspond to valid N_PORT fabric IDs.
Since fibre channel addressing rules prohibit the assignment of fabric addresses with a domain ID of 0, the above codes will never correspond to valid N_PORT fabric IDs.
If the sending gateway cannot obtain the worldwide identifier of an N_PORT, the gateway SHALL terminate the request with an LS_RJT message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
If the sending gateway cannot obtain the worldwide identifier of an N_PORT, the gateway SHALL terminate the request with an LS_RJT message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
Supplemental data is sent with the link service request or ACC frames in one of the following ways:
Supplemental data is sent with the link service request or ACC frames in one of the following ways:
a) By appending the necessary data to the end of the link service
frame.
a) By appending the necessary data to the end of the link service frame.
b) By extending the sequence with additional frames.
b) By extending the sequence with additional frames.
In the first case, a new frame SHALL be created whose length includes the supplemental data. The procedure for extending the link service sequence with additional frames is dependent on the link service type.
In the first case, a new frame SHALL be created whose length includes the supplemental data. The procedure for extending the link service sequence with additional frames is dependent on the link service type.
Monia, et al. Standards Track [Page 59] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 59] RFC 4172 Internet Fibre Channel Networking September 2005
For each field requiring address translation, the receiving gateway SHALL reference the translation type encoded in the field and replace it with the N_PORT address as shown in Table 7.
For each field requiring address translation, the receiving gateway SHALL reference the translation type encoded in the field and replace it with the N_PORT address as shown in Table 7.
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+
+------------------+------------------------------------+ | Translation | N_PORT Translation | | Type Code | | +------------------+------------------------------------+ | 0x00 00 01 | Replace field contents with N_PORT | | | alias of frame originator. | +------------------+------------------------------------+ | 0x00 00 02 | Replace field contents with N_PORT | | | ID of frame recipient. | +------------------+------------------------------------+ | | Lookup N_PORT via iSNS query. | | | If locally attached, replace with | | 0x00 00 03 | N_PORT ID. | | | If remotely attached, replace with | | | N_PORT alias from remote N_PORT. | | | descriptor (see Section 5.2.2.1). | +------------------+------------------------------------+
Table 7. Link Service Address Translation
Table 7. Link Service Address Translation
For translation type 3, the receiving gateway SHALL obtain the information needed to fill in the field in the link service frame payload by converting the specified N_PORT worldwide identifier to a gateway IP address and N_PORT ID. This information MUST be obtained through an iSNS name server query. If the query is unsuccessful, the gateway SHALL terminate the request with an LS_RJT response message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
For translation type 3, the receiving gateway SHALL obtain the information needed to fill in the field in the link service frame payload by converting the specified N_PORT worldwide identifier to a gateway IP address and N_PORT ID. This information MUST be obtained through an iSNS name server query. If the query is unsuccessful, the gateway SHALL terminate the request with an LS_RJT response message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
After applying the supplemental data, the receiving gateway SHALL forward the resulting link service frames to the destination N_PORT with the supplemental information removed.
After applying the supplemental data, the receiving gateway SHALL forward the resulting link service frames to the destination N_PORT with the supplemental information removed.
Monia, et al. Standards Track [Page 60] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 60] RFC 4172 Internet Fibre Channel Networking September 2005
7.3. Fibre Channel Link Services Processed by iFCP
7.3. Fibre Channel Link Services Processed by iFCP
The following Extended and FC-4 Link Service Messages must receive special processing.
The following Extended and FC-4 Link Service Messages must receive special processing.
Extended Link Service LS_COMMAND Mnemonic
Messages ---------- --------
----------------------
Abort Exchange 0x06 00 00 00 ABTX
Discover Address 0x52 00 00 00 ADISC
Discover Address Accept 0x02 00 00 00 ADISC ACC
FC Address Resolution 0x55 00 00 00 FARP-REPLY
Protocol Reply
FC Address Resolution 0x54 00 00 00 FARP-REQ
Protocol Request
Logout 0x05 00 00 00 LOGO
Port Login 0x30 00 00 00 PLOGI
Read Exchange Concise 0x13 00 00 00 REC
Read Exchange Concise 0x02 00 00 00 REC ACC
Accept
Read Exchange Status Block 0x08 00 00 00 RES
Read Exchange Status Block 0x02 00 00 00 RES ACC
Accept
Read Link Error Status 0x0F 00 00 00 RLS
Block
Read Sequence Status Block 0x09 00 00 00 RSS
Reinstate Recovery 0x12 00 00 00 RRQ
Qualifier
Request Sequence 0x0A 00 00 00 RSI
Initiative
Scan Remote Loop 0x7B 00 00 00 SRL
Third Party Process Logout 0x24 00 00 00 TPRLO
Third Party Process Logout 0x02 00 00 00 TPRLO ACC
Accept
Extended Link Service LS_COMMAND Mnemonic Messages ---------- -------- ---------------------- Abort Exchange 0x06 00 00 00 ABTX Discover Address 0x52 00 00 00 ADISC Discover Address Accept 0x02 00 00 00 ADISC ACC FC Address Resolution 0x55 00 00 00 FARP-REPLY Protocol Reply FC Address Resolution 0x54 00 00 00 FARP-REQ Protocol Request Logout 0x05 00 00 00 LOGO Port Login 0x30 00 00 00 PLOGI Read Exchange Concise 0x13 00 00 00 REC Read Exchange Concise 0x02 00 00 00 REC ACC Accept Read Exchange Status Block 0x08 00 00 00 RES Read Exchange Status Block 0x02 00 00 00 RES ACC Accept Read Link Error Status 0x0F 00 00 00 RLS Block Read Sequence Status Block 0x09 00 00 00 RSS Reinstate Recovery 0x12 00 00 00 RRQ Qualifier Request Sequence 0x0A 00 00 00 RSI Initiative Scan Remote Loop 0x7B 00 00 00 SRL Third Party Process Logout 0x24 00 00 00 TPRLO Third Party Process Logout 0x02 00 00 00 TPRLO ACC Accept
FC-4 Link Service Messages LS_COMMAND Mnemonic
-------------------------- ---------- --------
FCP Read Exchange Concise 0x13 00 00 00 FCP REC
FCP Read Exchange Concise 0x02 00 00 00 FCP REC
Accept ACC
FC-4 Link Service Messages LS_COMMAND Mnemonic -------------------------- ---------- -------- FCP Read Exchange Concise 0x13 00 00 00 FCP REC FCP Read Exchange Concise 0x02 00 00 00 FCP REC Accept ACC
Each encapsulated fibre channel frame that is part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, as specified in Section 5.3.1. If an ACC link service response requires special processing, the responding gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the
Each encapsulated fibre channel frame that is part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, as specified in Section 5.3.1. If an ACC link service response requires special processing, the responding gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the
Monia, et al. Standards Track [Page 61] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 61] RFC 4172 Internet Fibre Channel Networking September 2005
link service request frame, in the LS_COMMAND_ACC field of the ACC encapsulation header. Supplemental data (if any) MUST be appended as described in the following section.
link service request frame, in the LS_COMMAND_ACC field of the ACC encapsulation header. Supplemental data (if any) MUST be appended as described in the following section.
The format of each special link service message, including supplemental data, where applicable, is shown in the following sections. Each description shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below.
The format of each special link service message, including supplemental data, where applicable, is shown in the following sections. Each description shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below.
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | LS_COMMAND |
+------+------------+------------+-----------+----------+
| 1 | |
| . | |
| . | Link Service Frame Payload |
| | |
| n | |
+======+============+============+===========+==========+
| n+1 | |
| . | Supplemental Data |
| . | (if any) |
| n+k | |
+======+================================================+
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | LS_COMMAND | +------+------------+------------+-----------+----------+ | 1 | | | . | | | . | Link Service Frame Payload | | | | | n | | +======+============+============+===========+==========+ | n+1 | | | . | Supplemental Data | | . | (if any) | | n+k | | +======+================================================+
Figure 20. Special Link Service Frame Payload
Figure 20. Special Link Service Frame Payload
Monia, et al. Standards Track [Page 62] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 62] RFC 4172 Internet Fibre Channel Networking September 2005
7.3.1. Special Extended Link Services
7.3.1. Special Extended Link Services
The following sections define extended link services for which special processing is required.
The following sections define extended link services for which special processing is required.
7.3.1.1. Abort Exchange (ABTX)
7.3.1.1. Abort Exchange (ABTX)
ELS Format:
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | RRQ Status | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange|
+------+------------+------------+-----------+----------+
| 3-10 | Optional association header (32 bytes |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | RRQ Status | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| +------+------------+------------+-----------+----------+ | 3-10 | Optional association header (32 bytes | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------
-----------
Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------ -----------
Exchange Originator 1, 2 N/A
S_ID
Exchange Originator 1, 2 N/A S_ID
Other Special Processing:
Other Special Processing:
None.
None.
Monia, et al. Standards Track [Page 63] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 63] RFC 4172 Internet Fibre Channel Networking September 2005
7.3.1.2. Discover Address (ADISC)
7.3.1.2. Discover Address (ADISC)
Format of ADISC ELS:
Format of ADISC ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT ID of ELS Originator | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------- ------------
N_PORT ID of ELS 1 N/A
Originator
N_PORT ID of ELS 1 N/A Originator
Other Special Processing:
Other Special Processing:
The Hard Address of the ELS originator SHALL be set to 0.
The Hard Address of the ELS originator SHALL be set to 0.
Monia, et al. Standards Track [Page 64] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 64] RFC 4172 Internet Fibre Channel Networking September 2005
7.3.1.3. Discover Address Accept (ADISC ACC)
7.3.1.3. Discover Address Accept (ADISC ACC)
Format of ADISC ACC ELS:
Format of ADISC ACC ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT ID of ELS Originator | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------- ------------
N_PORT ID of ELS 1 N/A
Originator
N_PORT ID of ELS 1 N/A Originator
Other Special Processing:
Other Special Processing:
The Hard Address of the ELS originator SHALL be set to 0.
The Hard Address of the ELS originator SHALL be set to 0.
Monia, et al. Standards Track [Page 65] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 65] RFC 4172 Internet Fibre Channel Networking September 2005
7.3.1.4. FC Address Resolution Protocol Reply (FARP-REPLY)
7.3.1.4. FC Address Resolution Protocol Reply (FARP-REPLY)
The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see Section 7.3.1.5) to perform the address resolution services required by the FC-VI protocol [FC-VI] and the fibre channel mapping of IP and ARP specified in RFC 2625 [RFC2625].
The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see Section 7.3.1.5) to perform the address resolution services required by the FC-VI protocol [FC-VI] and the fibre channel mapping of IP and ARP specified in RFC 2625 [RFC2625].
Format of FARP-REPLY ELS:
Format of FARP-REPLY ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Match Addr | Requesting N_PORT Identifier | | | Code Points| | +------+------------+------------+-----------+----------+ | 2 | Responder | Responding N_PORT Identifier | | | Action | | +------+------------+------------+-----------+----------+ | 3-4 | Requesting N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 5-6 | Requesting N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 7-8 | Responding N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 9-10 | Responding N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 11-14| Requesting N_PORT IP Address | +------+------------+------------+-----------+----------+ | 15-18| Responding N_PORT IP Address | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
------------
Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ----------------- ------------
Requesting N_PORT 2 N/A
Identifier
Requesting N_PORT 2 N/A Identifier
Responding N_PORT 1 N/A
Identifier
Responding N_PORT 1 N/A Identifier
Other Special Processing:
Other Special Processing:
None.
None.
Monia, et al. Standards Track [Page 66] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 66] RFC 4172 Internet Fibre Channel Networking September 2005
7.3.1.5. FC Address Resolution Protocol Request (FARP-REQ)
7.3.1.5. FC Address Resolution Protocol Request (FARP-REQ)
The FARP-REQ ELS is used in conjunction with the FC-VI protocol [FC-VI] and IP-to-FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs.
The FARP-REQ ELS is used in conjunction with the FC-VI protocol [FC-VI] and IP-to-FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs.
Section 9.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric.
Section 9.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric.
Format of FARP_REQ ELS:
Format of FARP_REQ ELS:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x54| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Addrを合わせてください。| 要求N_ポート識別子| | | コード・ポイント| | +------+------------+------------+-----------+----------+ | 2 | 応答者| 応じNる_ポート識別子| | | 動作| | +------+------------+------------+-----------+----------+ | 3-4 | ポート_が命名するN_ポートを要求します。| +------+------------+------------+-----------+----------+ | 5-6 | 要求N_ポートノード_名| +------+------------+------------+-----------+----------+ | 7-8 | 応じNる_ポートポート_名| +------+------------+------------+-----------+----------+ | 9-10 | 応じNる_ポートノード_名| +------+------------+------------+-----------+----------+ | 11-14| N_ポートIPアドレスを要求します。| +------+------------+------------+-----------+----------+ | 15-18| 応じNる_ポートIPアドレス| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)----------------- -----------
Requesting N_PORT 3 Requesting N_PORT
Identifier Port Name
N_ポート3要求N_ポート識別子ポート名を要求します。
Responding N_PORT 3 Responding N_PORT
Identifier Port Name
応じNる_ポート3の応じNる_ポート識別子ポート名
Monia, et al. Standards Track [Page 67] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[67ページ]RFC4172インターネット繊維チャンネル
Other Special Processing:
他の特別な処理:
None.
なし。
7.3.1.6. Logout (LOGO) and LOGO ACC
7.3.1.6. ログアウト、(ロゴ)とロゴACC
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x5| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| ログアウトされるN_PORT ID| +------+------------+------------+-----------+----------+ | 2-3 | LOGO創始者(8バイト)のポート名| +======+============+============+===========+==========+
This ELS SHALL always be sent as a special ELS regardless of the translation mode in effect.
このELS SHALL、事実上、翻訳モードにかかわらず特別なELSとしていつも送ってください。
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)--------------- -----------
N_PORT ID Being 1 N/A
Logged Out
1であるN_ポートID、なし、ログアウトされます。
Other Special Processing:
他の特別な処理:
See Section 5.2.3.
セクション5.2.3を見てください。
7.3.1.7. Port Login (PLOGI) and PLOGI ACC
7.3.1.7. ポートログイン(PLOGI)とPLOGI ACC
A PLOGI ELS establishes fibre channel communications between two N_PORTs and triggers the creation of an iFCP session if one does not exist.
PLOGI ELSは2N_PORTsの繊維チャンネルコミュニケーションを確立して、1つが存在していないなら、iFCPセッションの作成の引き金となります。
The PLOGI request and ACC response carry information identifying the originating N_PORT, including a specification of its capabilities. If the destination N_PORT accepts the login request, it sends an Accept response (an ACC frame with PLOGI payload) specifying its capabilities. This exchange establishes the operating environment for the two N_PORTs.
PLOGI要求とACC応答は能力の仕様を含む起因しているN_PORTを特定する情報を運びます。 目的地N_PORTがログイン要求を受け入れるなら、それで、Accept応答(PLOGIペイロードがあるACCフレーム)は能力を指定します。 この交換は2N_PORTsのために操作環境を確立します。
Monia, et al. Standards Track [Page 68] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[68ページ]RFC4172インターネット繊維チャンネル
The following figure is duplicated from [FC-FS], and shows the PLOGI message format for both the request and Accept (ACC) response. An N_PORT will reject a PLOGI request by transmitting an LS_RJT message containing no payload.
以下の図は、要求とAccept(ACC)応答の両方のために[FC-FS]からコピーされて、PLOGIメッセージ・フォーマットを示しています。 N_PORTは、ペイロードを全く含まないLS_RJTメッセージを送ることによって、PLOGI要求を拒絶するでしょう。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x3| 0×00| 0×00| 0×00| | | Acc=0x2| | | | +------+------------+------------+-----------+----------+ | 1-4 | 共益サービスパラメタ| +------+------------+------------+-----------+----------+ | 5-6 | N_ポート名| +------+------------+------------+-----------+----------+ | 7-8 | ノード名| +------+------------+------------+-----------+----------+ | 9-12 | クラス1サービスパラメタ| +------+------------+------------+-----------+----------+ |13-17 | クラス2サービスパラメタ| +------+------------+------------+-----------+----------+ |18-21 | クラス3サービスパラメタ| +------+------------+------------+-----------+----------+ |22-25 | クラス4サービスパラメタ| +------+------------+------------+-----------+----------+ |26-29 | ベンダーバージョンレベル| +======+============+============+===========+==========+
Figure 21. Format of PLOGI Request and ACC Payloads
図21。 PLOGI要求とACC有効搭載量の形式
Details of the above fields, including common and class-based service parameters, can be found in [FC-FS].
[FC-FS]で一般的でクラスベースのサービスパラメタを含む上の分野の詳細を見つけることができます。
Special Processing
特別な処理
As specified in Section 5.2.2.2, a PLOGI request addressed to a
remotely attached N_PORT MUST cause the creation of an iFCP
session if one does not exist. Otherwise, the PLOGI and PLOGI ACC
payloads MUST be passed through without modification to the
destination N_PORT using the existing iFCP session. In either
case, the SPC bit must be set in the frame encapsulation header as
specified in 5.3.3.
.2、PLOGIは、1つが存在していないなら.2が、セクション5.2で指定されるように原因がiFCPセッションの作成であるとほんの少し付属しているN_PORT MUSTに扱ったよう要求します。 さもなければ、既存のiFCPセッションを使用して、目的地N_PORTへの変更なしでPLOGIとPLOGI ACCペイロードを通り抜けなければなりません。 どちらの場合ではも、指定されるようにフレームカプセル化ヘッダーにSPCビットを設定しなければならない、5.3、.3
If the CBIND to create the iFCP session fails, the issuing gateway
SHALL terminate the PLOGI with an LS_RJT response. The Reason
Code and Reason Code Explanation SHALL be selected from Table 8
based on the CBIND failure status.
iFCPセッションを作成するCBINDが失敗するなら、発行ゲートウェイSHALLはLS_RJT応答でPLOGIを終えます。 Reason CodeとReason Code Explanation SHALL、CBIND失敗状態に基づくTable8から、選択されてください。
Monia, et al. Standards Track [Page 69] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[69ページ]RFC4172インターネット繊維チャンネル
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
+---------------+-------------------+---------------------+ | CBINDの故障| LS_RJT理由| LS_RJT理由コード| | 状態| コード| 説明| +===============+===================+=====================+ | 不特定| 働くことができません。| いいえ追加しています。| | 理由(16)| コマンド要求| 説明(0×00)| | | (0×09) | | +---------------+-------------------+---------------------+ | そのようなものでない| 働くことができません。| 無効のN_ポート| | デバイス(17)| コマンド要求| 名前(0x0D)| | | (0×09) | | +---------------+-------------------+---------------------+ | 欠けています。| 働くことができません。| 不十分| | リソース(19)| コマンド要求| サポートするリソース| | | (0×09) | ログイン(0×29)| +---------------+-------------------+---------------------+ | 非互換| 働くことができません。| いいえ追加しています。| | アドレス| コマンド要求| 説明(0×00)| | 翻訳| (0×09) | | | モード(20)| | | +---------------+-------------------+---------------------+ | 不正確なiFCP| 働くことができません。| いいえ追加しています。| | プロトコル| コマンド要求| 説明(0×00)| | バージョンNumber| (0×09) | | | (21) | | | +---------------+-------------------+---------------------+ | ゲートウェイ| 働くことができません。| いいえ追加しています。| | 連動します。| コマンド要求| 説明(0×00)| | (22) | (0×09) | | +---------------+-------------------+---------------------+
Table 8. PLOGI LS_RJT Status for CBIND Failures
8を見送ってください。 CBINDの故障のためのPLOGI LS_RJT状態
Monia, et al. Standards Track [Page 70] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[70ページ]RFC4172インターネット繊維チャンネル
7.3.1.8. Read Exchange Concise (REC)
7.3.1.8. 簡潔な状態で交換を読んでください。(REC)
Link Service Request Format:
サービスのリクエスト形式をリンクしてください:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
| | (present only for translation type 3) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15|ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x13| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| 交換創始者S_ID| +------+------------+------------+-----------+----------+ | 2 | 雄牛_ID| RX_ID| +======+============+============+===========+==========+ | 3-4 |Exchange Originator(8バイト)のポートName| | | (翻訳タイプ3のためだけに現在)です。 | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)----------------- -----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange Originator
S_ID交換創始者の交換創始者1、2、または3ポート名
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 71] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[71ページ]RFC4172インターネット繊維チャンネル
7.3.1.9. Read Exchange Concise Accept (REC ACC)
7.3.1.9. 交換が簡潔な状態で読まれて、受け入れてください。(REC ACC)
Format of REC ACC Response:
REC ACC応答の形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Originator Address Identifier |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Responder Address Identifier |
+------+------------+------------+-----------+----------+
| 4 | FC4VALUE (FC-4-Dependent Value) |
+------+------------+------------+-----------+----------+
| 5 | E_STAT (Exchange Status) |
+======+============+============+===========+==========+
| 6-7 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
| 8-9 |Port Name of the Exchange Responder (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15|ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Acc=0x02| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | 雄牛_ID| RX_ID| +------+------------+------------+-----------+----------+ | 2 | Rsvd| 創始者アドレス識別子| +------+------------+------------+-----------+----------+ | 3 | Rsvd| 応答者アドレス識別子| +------+------------+------------+-----------+----------+ | 4 | FC4VALUE(FC4扶養家族値)| +------+------------+------------+-----------+----------+ | 5 | E_スタット(交換状態)| +======+============+============+===========+==========+ | 6-7 |Exchange Originator(8バイト)のポートName| +======+============+============+===========+==========+ | 8-9 |Exchange Responder(8バイト)のポートName| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Originator Address 1, 2, or 3 Port Name of the
Identifier Exchange Originator
識別子交換創始者の創始者アドレス1、2、または3ポート名
Responder Address 1, 2, or 3 Port Name of the
Identifier Exchange Responder
識別子交換応答者の応答者アドレス1、2、または3ポート名
When supplemental data is required, the frame SHALL always be extended by 4 words as shown above. If the translation type for the Originator Address Identifier or the Responder Address Identifier is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
補足しているとき、データが必要であり、フレームはSHALLです。示されるとして上でいつも4つの単語によって広げられてください。 Originator Address IdentifierかResponder Address Identifierのための翻訳タイプが1か2歳であるなら、存在という対応する8バイトのポート名のSHALLはすべてのゼロにセットしました。
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 72] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[72ページ]RFC4172インターネット繊維チャンネル
7.3.1.10. Read Exchange Status Block (RES)
7.3.1.10. 交換状態ブロックを読んでください。(RES)
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
| 11-12| Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x13| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| 交換創始者S_ID| +------+------------+------------+-----------+----------+ | 2 | 雄牛_ID| RX_ID| +------+------------+------------+-----------+----------+ | 3-10 | 協会Header(任意にreqな**dであるかもしれません)| +======+============+============+===========+==========+ | 11-12| Exchange Originator(8バイト)のポートName| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange Originator
S_ID交換創始者の交換創始者1、2、または3ポート名
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 73] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[73ページ]RFC4172インターネット繊維チャンネル
7.3.1.11. Read Exchange Status Block Accept (RES ACC)
7.3.1.11. 交換状態ブロックが読まれて、受け入れてください。(RES ACC)
Format of ELS Accept Response:
高架鉄道の形式は応答を受け入れます:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Exchange Originator N_PORT ID |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Exchange Responder N_PORT ID |
+------+------------+------------+-----------+----------+
| 4 | Exchange Status Bits |
+------+------------+------------+-----------+----------+
| 5 | Reserved |
+------+------------+------------+-----------+----------+
| 6-n | Service Parameters and Sequence Statuses |
| | as described in [FC-FS] |
+======+============+============+===========+==========+
|n+1- | Port Name of the Exchange Originator (8 bytes) |
|n+2 | |
+======+============+============+===========+==========+
|n+3- | Port Name of the Exchange Responder (8 bytes) |
|n+4 | |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Acc=0x02| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | 雄牛_ID| RX_ID| +------+------------+------------+-----------+----------+ | 2 | Rsvd| 交換創始者N_はIDを移植します。| +------+------------+------------+-----------+----------+ | 3 | Rsvd| 交換応答者N_はIDを移植します。| +------+------------+------------+-----------+----------+ | 4 | 交換ステータスビット| +------+------------+------------+-----------+----------+ | 5 | 予約されます。| +------+------------+------------+-----------+----------+ | 6-n| サービスパラメタと系列状態| | | 説明されたコネ[FC-FS]として| +======+============+============+===========+==========+ |n+1、-| Exchange Originator(8バイト)のポートName| |n+2| | +======+============+============+===========+==========+ |n+3、-| Exchange Responder(8バイト)のポートName| |n+4| | +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Exchange Originator 1, 2, or 3 Port Name of the
N_PORT ID Exchange Originator
N_ポートID交換創始者の交換創始者1、2、または3ポート名
Exchange Responder 1, 2, or 3 Port Name of the
N_PORT ID Exchange Responder
N_ポートID交換応答者の交換応答者1、2、または3ポート名
When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. If the translation type for the Exchange Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
補足のデータが必要であるときにELS SHALL、4つの単語で、上に示されるように、広げられてください。 Exchange Originator N_PORT IDかExchange Responder N_PORT IDのための翻訳タイプが1か2歳であるなら、存在という対応する8バイトのポート名のSHALLはすべてのゼロにセットしました。
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 74] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[74ページ]RFC4172インターネット繊維チャンネル
7.3.1.12. Read Link Error Status (RLS)
7.3.1.12. リンクエラー状況を読んでください。(RLS)
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT Identifier |
+======+============+============+===========+==========+
| 2-3 | Port Name of the N_PORT (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmdは0x0Fと等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| N_ポート識別子| +======+============+============+===========+==========+ | 2-3 | N_PORT(8バイト)のポートName| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)----------------- -----------
N_PORT Identifier 1, 2, or 3 Port Name of the
N_PORT
N_ポートのN_ポート識別子1、2、または3ポート名
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 75] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[75ページ]RFC4172インターネット繊維チャンネル
7.3.1.13. Read Sequence Status Block (RSS)
7.3.1.13. 系列状態ブロックを読んでください。(RSS)
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | SEQ_ID | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x09| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | SEQ_ID| 交換創始者S_ID| +------+------------+------------+-----------+----------+ | 2 | 雄牛_ID| RX_ID| +======+============+============+===========+==========+ | 3-4 |Exchange Originator(8バイト)のポートName| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Exchange Originator 1, 2, or 3 Port Name of the
S_ID Exchange Originator
S_ID交換創始者の交換創始者1、2、または3ポート名
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 76] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[76ページ]RFC4172インターネット繊維チャンネル
7.3.1.14. Reinstate Recovery Qualifier (RRQ)
7.3.1.14. 回復資格を与える人を復職させてください。(RRQ)
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x12| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| 交換創始者S_ID| +------+------------+------------+-----------+----------+ | 2 | 雄牛_ID| RX_ID| +------+------------+------------+-----------+----------+ | 3-10 | 協会Header(任意にreqな**dであるかもしれません)| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Exchange Originator 1 or 2 N/A
S_ID
なし、交換創始者1か2S_ID
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 77] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[77ページ]RFC4172インターネット繊維チャンネル
7.3.1.15. Request Sequence Initiative (RSI)
7.3.1.15. 系列イニシアチブを要求してください。(RSI)
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmdは0x0Aと等しいです。| 0×00| 0×00| 0×00| +------+------------+------------+-----------+----------+ | 1 | Rsvd| 交換創始者S_ID| +------+------------+------------+-----------+----------+ | 2 | 雄牛_ID| RX_ID| +------+------------+------------+-----------+----------+ | 3-10 | 協会Header(任意にreqな**dであるかもしれません)| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Exchange Originator 1 or 2 N/A
S_ID
なし、交換創始者1か2S_ID
Other Special Processing:
他の特別な処理:
None.
なし。
Monia, et al. Standards Track [Page 78] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[78ページ]RFC4172インターネット繊維チャンネル
7.3.1.16. Scan Remote Loop (SRL)
7.3.1.16. リモート折返しをスキャンしてください。(SRL)
SRL allows a remote loop to be scanned to detect changes in the device configuration. Any changes will trigger a fibre channel state change notification and subsequent update of the iSNS database.
SRLは、リモート折返しがデバイス構成における変化を検出するためにスキャンされるのを許容します。 どんな変化もiSNSデータベースの繊維チャンネル州の変更届出書とその後のアップデートの引き金となるでしょう。
ELS Format:
高架鉄道形式:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x7B | Reserved |
+------+------------+------------+-----------+----------+
| 1 | Flag | Address Identifier of the FL_PORT |
| | | (see B.1) |
+======+============+============+===========+==========+
| 2-3 | Worldwide Name of the Remote FL_PORT |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmdは0x7Bと等しいです。| 予約されます。| +------+------------+------------+-----------+----------+ | 1 | 旗| フロリダ_ポートに関するアドレス識別子| | | | (B.1を見ます) | +======+============+============+===========+==========+ | 2-3 | 遠く離れたフロリダ_ポートの世界的な名前| +======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
分野Requiring Translation Supplemental Data Address Translation Type、(見てください、(3だけをタイプしてください)-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、セクション7.2)------------------ -----------
Address Identifier 3 Worldwide Name of
of the FL_PORT the Remote FL_PORT
遠く離れたフロリダ_が移植するフロリダ_ポートについて識別子3の世界的な名を扱います。
Other Special Processing:
他の特別な処理:
The D_ID field is the address of the Domain Controller associated
with the remote loop. The format of the Domain Controller address
is the hex 'FF FC' || Domain_ID, where Domain_ID is the gateway-
assigned alias representing the remote gateway or switch element
being queried. After translation by the remote gateway, the D_ID
identifies the gateway or switch element to be scanned within the
remote gateway region.
D_ID分野はリモート折返しに関連しているDomain Controllerのアドレスです。 Domain Controllerアドレスの形式は十六進法'FF FC'です。|| ドメイン_ID。(そこでは、Domain_IDが質問されるリモートゲートウェイかスイッチ素子を表しながら通称割り当てられたゲートウェイです)。 リモートゲートウェイのそばでの翻訳の後に、D_IDは、遠く離れたゲートウェイ領域の中でスキャンされるためにゲートウェイかスイッチ素子を特定します。
The FLAG field defines the scope of the SRL. If set to 0, all
loop port interfaces on the given switch element or gateway are
scanned. If set to one, the loop port interface on the gateway or
switch element to be scanned MUST be specified in bits 8 through
31.
FLAG分野はSRLの範囲を定義します。 0に設定されるなら、与えられたスイッチ素子かゲートウェイの上のすべての輪のポートインタフェースがスキャンされます。 1つに設定されるなら、ビットで8〜31にスキャンされるべきゲートウェイかスイッチ素子の上の輪のポートインタフェースを指定しなければなりません。
If the Flag field is zero, the SRL request SHALL NOT be sent as a
special ELS.
Flag分野がそうなら、ゼロ、SRLは、SHALL NOTが特別なELSとして送られるよう要求します。
Monia, et al. Standards Track [Page 79] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[79ページ]RFC4172インターネット繊維チャンネル
If the Domain_ID represents a remote switch or gateway and an iFCP
session to the remote Domain Controller does not exist, the
requesting gateway SHALL create the iFCP session.
Domain_IDがリモート・スイッチかゲートウェイを表して、リモートDomain ControllerへのiFCPセッションが存在していないなら、要求ゲートウェイSHALLはiFCPセッションを作成します。
7.3.1.17. Third Party Process Logout (TPRLO)
7.3.1.17. 第三者プロセスはログアウトします。(TPRLO)
TPRLO provides a mechanism for an N_PORT (third party) to remove one or more process login sessions that exist between the destination N_PORT and other N_PORTs specified in the command. This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which, when combined with the destination N_PORT, identifies a process login to be terminated by the command.
N_PORT(第三者)が目的地N_PORTとコマンドで指定された他のN_PORTsの間に存在する1つ以上のプロセスログインセッションを取り除くように、TPRLOはメカニズムを提供します。 このコマンドは1TPRLO LOGOUT PARAMETER PAGEsを含んでいます。目的地N_PORTに結合されると、それは、コマンドで終えられるためにそれぞれプロセスログインを特定します。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
+--------+------------+--------------------+----------------------+ | Word| ビット0-7| ビット8-15| ビット16--31| +--------+------------+--------------------+----------------------+ | 0 | Cmd=0x24| ページ長(0×10)| ペイロード長| +--------+------------+--------------------+----------------------+ | 1 | TPRLOがログアウトする、パラメタ0ページ| +--------+--------------------------------------------------------+ | 5 | TPRLOがログアウトする、パラメタ1ページ| +--------+--------------------------------------------------------+ .... +--------+--------------------------------------------------------+ |(4*n)+1 | TPRLO Logout Parameter nページ| +--------+--------------------------------------------------------+
Figure 22. Format of TPRLO ELS
図22。 TPRLO高架鉄道の形式
Each TPRLO parameter page contains parameters identifying one or more image pairs and may be associated with a single FC-4 protocol type that is common to all FC-4 protocol types between the specified image pair or global to all specified image pairs. The format of a TPRLO page requiring address translation is shown in Figure 23. Additional information on TPRLO can be found in [FC-FS].
それぞれのTPRLOパラメタページは、1イメージ組以上を特定するパラメタを含んでいて、指定されたイメージ組の間のすべてのFC-4プロトコルタイプに一般的であるか、またはすべての指定されたイメージ組に、グローバルな単独のFC-4プロトコルタイプに関連しているかもしれません。 アドレス変換を必要とする1TPRLOページの書式は図23に示されます。 [FC-FS]でTPRLOに関する追加情報を見つけることができます。
Monia, et al. Standards Track [Page 80] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[80ページ]RFC4172インターネット繊維チャンネル
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-31 |
+------+------------+------------+-----------+----------+
| 0 | TYPE Code | TYPE CODE | |
| | or | EXTENSION | TPRLO Flags |
| | Common SVC | | |
| | Parameters | | |
+------+------------+------------+-----------+----------+
| 1 | Third Party Process Associator |
+------+------------+------------+-----------+----------+
| 2 | Responder Process Associator |
+------+------------+------------+-----------+----------+
| 3 | Reserved | Third Party Originator N_PORT ID |
+======+============+============+===========+==========+
| 4-5 | Worldwide Name of Third Party Originator |
| | N_PORT |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15| ビット16-31| +------+------------+------------+-----------+----------+ | 0 | コードをタイプしてください。| コードをタイプしてください。| | | | または| 拡大| TPRLO旗| | | 一般的なSVC| | | | | パラメタ| | | +------+------------+------------+-----------+----------+ | 1 | 第三者プロセス連想装置| +------+------------+------------+-----------+----------+ | 2 | 応答者プロセス連想装置| +------+------------+------------+-----------+----------+ | 3 | 予約されます。| 第三者創始者N_はIDを移植します。| +======+============+============+===========+==========+ | 4-5 | 第三者創始者の世界的な名前| | | N_ポート| +------+------------------------------------------------+
Figure 23. Format of an Augmented TPRLO Parameter Page
図23。 増大しているTPRLOパラメタページの形式
The TPRLO flags that affect supplemented ELS processing are as follows:
補われたELS処理に影響するTPRLO旗は以下の通りです:
Bit 18: Third party Originator N_PORT Validity. When set to one,
this bit indicates that word 3, bits 8-31 (Third Party
Originator N_PORT ID), are meaningful.
ビット18: 第三者Originator N_PORT Validity。 1つに設定されると、このビットは、Word3(ビット8-31(第3パーティOriginator N_PORT ID))が重要であることを示します。
Bit 19: Global Process logout. When set to one, this bit indicates
that all image pairs for all N_PORTs of the specified FC-4
protocol shall be invalidated. When the value of this bit
is one, only one logout parameter page is permitted in the
TPRLO payload.
ビット19: グローバルなProcessはログアウトします。 1つに設定されると、このビットは、指定されたFC-4プロトコルのすべてのN_PORTsのためのすべてのイメージ組が無効にされるのを示します。 このビットの価値が1、1だけがログアウトするということであるときに、パラメタページはTPRLOペイロードで受入れられます。
If bit 18 has a value of zero and bit 19 has a value of one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS.
ビット18にゼロとビット19の価値があるなら、特別なELSとして旗がさばくTPRLO、当時のELS SHALL NOTの1の値を送りましたか?
Otherwise, the originating gateway SHALL process the ELS as follows:
さもなければ、起因するゲートウェイSHALLは以下のELSを処理します:
a) The first word of the TPRLO payload SHALL NOT be modified.
a) 変更されていて、1番目はTPRLOペイロードSHALL NOTについて言い表します。
b) Each TPRLO parameter page shall be extended by two words as shown
in Figure 23.
b) それぞれのTPRLOパラメタページは図23に示されるように2つの単語によって広げられるものとします。
Monia, et al. Standards Track [Page 81] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[81ページ]RFC4172インターネット繊維チャンネル
c) If word 0, bit 18 (Third Party Originator N_PORT ID validity), in
the TPRLO flags field has a value of one, then the sender shall
place the worldwide port name of the fibre channel device's N_PORT
in the extension words. The N_PORT ID SHALL be set to 3.
Otherwise, the contents of the extension words and the Third Party
Originator N_PORT ID SHALL be set to zero.
c) 0、ビット18(3番目のパーティOriginator N_PORT IDの正当性)、分野にはTPRLO旗で、1の値があって、次に、送付者が拡大単語で世界的なポート名(繊維チャンネルデバイスのN_PORT)を置くものとするという単語であるなら。 N_PORT ID SHALL、3に設定されてください。 そうでなければ、コンテンツ、拡大単語とThirdパーティOriginator N_PORT ID SHALLでは、ゼロに設定されてください。
d) The ELS originator SHALL set the SPC bit in the encapsulation
header of each augmented frame comprising the ELS (see Section
5.3.1).
d) ELS創始者SHALLはELSを包括するそれぞれの増大しているフレームのカプセル化ヘッダーにSPCビットをはめ込みます(セクション5.3.1を見てください)。
e) If the ELS contains a single TPRLO parameter page, the originator
SHALL increase the frame length as necessary to include the
extended parameter page.
e) ELSが1TPRLOパラメタページを含んでいるなら、創始者SHALLは、拡張パラメタページを含むように必要に応じてフレームの長さを増強します。
f) If the ELS to be augmented contains multiple TPRLO parameter
pages, the FC frames created to contain the augmented ELS payload
SHALL NOT exceed the maximum frame size that can be accepted by
the destination N_PORT.
f) 増大するべきELSが複数のTPRLOパラメタページを含んでいるなら、増大しているELSペイロードSHALL NOTを含むように作成されたFCフレームは目的地N_PORTが受け入れることができる最大のフレーム・サイズを超えています。
Each fibre channel frame SHALL contain an integer number of
extended TPRLO parameter pages. The maximum number of extended
TPRLO parameter pages in a frame SHALL be limited to the number
that can be held without exceeding the above upper limit. New
frames resulting from the extension of the TPRLO pages to include
the supplemental data SHALL be created by extending the SEQ_CNT in
the fibre channel frame header. The SEQ_ID SHALL NOT be modified.
各繊維チャンネルフレームSHALLは拡張TPRLOパラメタページの整数を含んでいます。 制限されていて、拡張TPRLOパラメタの最大数はフレームに上の上限を超えていなくて保持できる数へSHALLを呼び出します。 新しいフレーム、補足のデータSHALLを含むTPRLOページの拡大から生じて、繊維チャンネルフレームヘッダーでSEQ_CNTを広げることによって、作成されてください。 SEQ_ID SHALL NOT、変更されてください。
The gateway receiving the augmented TPRLO ELS SHALL generate ELS frames to be sent to the destination N_PORT by copying word 0 of the ELS payload and processing each augmented parameter page as follows:
増大しているTPRLO ELS SHALLがコピーすることによって目的地N_PORTに送られるELSフレームであるとELSペイロードと処理の以下のそれぞれの増大しているパラメタページあたりのWord0に生成するゲートウェイ受信:
a) If word 0, bit 18, has a value of one, create a parameter page by
copying words 0 through 2 of the augmented parameter page. The
Third Party Originator N_PORT ID in word 3 shall be generated by
referencing the supplemental data as described in Section 7.2.
a) Word0(ビット18)に1の値があるなら、増大しているパラメタページの単語0〜2をコピーすることによって、パラメタページを作成してください。 Word3によるThirdパーティOriginator N_PORT IDは、セクション7.2で説明されるように補足のデータに参照をつけることによって、生成されるものとします。
b) If word 0, bit 18, has a value of zero, create a parameter page by
copying words 0 through 3 of the augmented parameter page.
b) Word0(ビット18)にゼロの値があるなら、増大しているパラメタページの単語0〜3をコピーすることによって、パラメタページを作成してください。
The size of each frame to be sent to the destination N_PORT MUST NOT exceed the maximum frame size that the destination N_PORT can accept. The sequence identifier in each frame header SHALL be copied from the augmented ELS, and the sequence count SHALL be monotonically increasing.
目的地N_PORT MUST NOTに送られるそれぞれのフレームのサイズは目的地N_PORTが受け入れることができる最大のフレーム・サイズを超えています。 増大しているELSからコピーされて、それぞれの系列識別子はヘッダーSHALLを縁どっています。系列カウントSHALLは増加する状態で単調にコピーされます。
Monia, et al. Standards Track [Page 82] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[82ページ]RFC4172インターネット繊維チャンネル
7.3.1.18. Third Party Logout Accept (TPRLO ACC)
7.3.1.18. 第三者がログアウトする、受諾(TPRLO ACC)
The format of the TPRLO ACC frame is shown in Figure 24.
TPRLO ACCフレームの書式は図24に示されます。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
+--------+------------+--------------------+----------------------+ | Word| ビット0-7| ビット8-15| ビット16--31| +--------+------------+--------------------+----------------------+ | 0 | Cmd=0x2| ページ長(0×10)| ペイロード長| +--------+------------+--------------------+----------------------+ | 1 | TPRLOがログアウトする、パラメタ0ページ| +--------+--------------------------------------------------------+ | 5 | TPRLOがログアウトする、パラメタ1ページ| +--------+--------------------------------------------------------+ .... +--------+--------------------------------------------------------+ |(4*n)+1 | TPRLO Logout Parameter nページ| +--------+--------------------------------------------------------+
Figure 24. Format of TPRLO ACC ELS
図24。 TPRLO ACC高架鉄道の形式
The format of the parameter page and rules for parameter page augmentation are as specified in Section 7.3.1.17.
パラメタページの形式とパラメタページ増大のための規則がセクション7.3.1で.17を指定するようにあります。
7.3.2. Special FC-4 Link Services
7.3.2. 特別なFC-4リンクサービス
The following sections define FC-4 link services for which special processing is required.
以下のセクションは特別な処理が必要であるFC-4リンクサービスを定義します。
7.3.2.1. FC-4 Link Services Defined by FCP
7.3.2.1. FCPによって定義されたFC-4リンクサービス
The format of FC-4 link service frames defined by FCP can be found in [FCP-2].
[FCP-2]でFCPによって定義されたFC-4リンクサービスフレームの形式を見つけることができます。
7.3.2.1.1. FCP Read Exchange Concise (FCP REC)
7.3.2.1.1. FCPは簡潔な状態で交換を読みます。(FCP REC)
The payload format for this link service is identical to the REC extended link service specified in Section 7.3.1.8 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against early revisions of FCP-2, an iFCP gateway MUST support both versions.
このリンクサービスのためのペイロード形式は拡張リンクサービスがセクション7.3.1の.8とSHALLで指定したRECと同じです。そのセクションで説明されていた状態で、処理されてください。 FC-4バージョンは[FCP-2]で時代遅れになるでしょう。 しかしながら、FCP-2の早めの改正に対して実装されたデバイスを支えるために、iFCPゲートウェイは両方のバージョンをサポートしなければなりません。
Monia, et al. Standards Track [Page 83] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[83ページ]RFC4172インターネット繊維チャンネル
7.3.2.1.2. FCP Read Exchange Concise Accept (FCP REC ACC)
7.3.2.1.2. 交換が簡潔な状態で読まれたFCPは受け入れます。(FCP REC ACC)
The payload format for this link service is identical to the REC ACC extended link service specified in Section 7.3.1.9 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against earlier revisions of FCP-2, an iFCP gateway MUST support both versions.
このリンクサービスのためのペイロード形式は拡張リンクサービスがセクション7.3.1の.9とSHALLで指定したREC ACCと同じです。そのセクションで説明されていた状態で、処理されてください。 FC-4バージョンは[FCP-2]で時代遅れになるでしょう。 しかしながら、FCP-2の以前の改正に対して実装されたデバイスを支えるために、iFCPゲートウェイは両方のバージョンをサポートしなければなりません。
7.4. FLOGI Service Parameters Supported by an iFCP Gateway
7.4. iFCPゲートウェイによってサポートされたFLOGIサービスパラメタ
The FLOGI ELS is issued by an N_PORT that wishes to access the fabric transport services.
FLOGI ELSは骨組みの輸送サービスにアクセスしたがっているN_PORTによって発行されます。
The format of the FLOGI request and FLOGI ACC payloads are identical to the PLOGI request and ACC payloads described in Section 7.3.1.7.
FLOGI要求とFLOGI ACCペイロードの形式はPLOGI要求と同じです、そして、ACCペイロードはセクション7.3.1で.7について説明しました。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+ | Word| ビット0-7| ビット8-15|ビット16-24|ビット25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd=0x4| 0×00| 0×00| 0×00| | | Acc=0x2| | | | +------+------------+------------+-----------+----------+ | 1-4 | 共益サービスパラメタ| +------+------------+------------+-----------+----------+ | 5-6 | N_ポート名| +------+------------+------------+-----------+----------+ | 7-8 | ノード名| +------+------------+------------+-----------+----------+ | 9-12 | クラス1サービスパラメタ| +------+------------+------------+-----------+----------+ |13-17 | クラス2サービスパラメタ| +------+------------+------------+-----------+----------+ |18-21 | クラス3サービスパラメタ| +------+------------+------------+-----------+----------+ |22-25 | クラス4サービスパラメタ| +------+------------+------------+-----------+----------+ |26-29 | ベンダーバージョンレベル| +======+============+============+===========+==========+
Figure 25. FLOGI Request and ACC Payload Format
図25。 FLOGI要求とACC有効搭載量形式
A full description of each parameter is given in [FC-FS].
[FC-FS]でそれぞれのパラメタの余すところのない解説を与えます。
This section tabulates the protocol-dependent service parameters supported by a fabric port attached to an iFCP gateway.
このセクションはiFCPゲートウェイに取り付けられた骨組みのポートによってサポートされたプロトコル依存するサービスパラメタについて表にします。
Monia, et al. Standards Track [Page 84] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[84ページ]RFC4172インターネット繊維チャンネル
The service parameters carried in the payload of an FLOGI extended link service request MUST be set in accordance with Table 9.
FLOGIのペイロードで運ばれたサービスパラメタはTableに従ったセットが9であったに違いないならリンクサービスのリクエストを広げました。
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
+-----------------------------------------+---------------+ | | 骨組みのログイン| | サービスパラメタ| クラス| | +---+---+---+---+ | | 1 | 2 | 3 | 4 | +-----------------------------------------+---+---+---+---+ | クラスの正当性| n| M| M| n| +-----------------------------------------+---+---+---+---+ | サービスオプション| | +-----------------------------------------+---+---+---+---+ | モードを混ぜてください。| n| n| n| n| +-----------------------------------------+---+---+---+---+ | 要求を接続して、積み重ねられます。| n| n| n| n| +-----------------------------------------+---+---+---+---+ | 連続した配送| n| M| M| n| +-----------------------------------------+---+---+---+---+ | ひたむきなシンプレクス| n| n| n| n| +-----------------------------------------+---+---+---+---+ | キャンプします。| n| n| n| n| +-----------------------------------------+---+---+---+---+ | バッファリングされたクラス1| n| n| n| n| +-----------------------------------------+---+---+---+---+ | 優先権| n| n| n| n| +-----------------------------------------+---+---+---+---+ | 創始者/受取人コントロール| | +-----------------------------------------+---+---+---+---+ | できる時計同期高架鉄道| n| n| n| n| +-----------------------------------------+---+---+---+---+
Table 9. FLOGI Service Parameter Settings
9を見送ってください。 FLOGIサービスパラメタ設定
Notes:
注意:
1) "n" indicates a parameter or capability that is not supported
by the iFCP protocol.
1) 「n」はiFCPプロトコルによってサポートされないパラメタか能力を示します。
2) "M" indicates an applicable parameter that MUST be supported by
an iFCP gateway.
2) 「M」はiFCPゲートウェイでサポートしなければならない適切なパラメタを示します。
Monia, et al. Standards Track [Page 85] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[85ページ]RFC4172インターネット繊維チャンネル
8. iFCP Error Detection
8. iFCP誤り検出
8.1. Overview
8.1. 概要
This section specifies provisions for error detection and recovery in addition to those in [FC-FS], which continue to be available in the iFCP network environment.
このセクションはiFCPネットワーク環境でずっと利用可能な[FC-FS]のそれらに加えて誤り検出と回復のための条項を指定します。
8.2. Stale Frame Prevention
8.2. 聞き古したフレーム防止
Recovery from fibre channel protocol error conditions requires that frames associated with a failed or aborted exchange drain from the fabric before exchange resources can be safely reused.
繊維チャンネルプロトコルエラー条件からの回復は、安全に交換リソースを再利用できる前に失敗したか中止になっている交換に関連しているフレームが骨組みから排水するのを必要とします。
Since a fibre channel fabric may not preserve frame order, there is no deterministic way to purge such frames. Instead, the fabric guarantees that frame the lifetime will not exceed a specific limit (R_A_TOV).
繊維チャンネル骨組みがフレームオーダーを保存しないかもしれないので、そのようなフレームを掃除するどんな決定論的な方法もありません。 代わりに、骨組みは、寿命が特定の限界(R_A_TOV)を超えないのをそのフレームに保証します。
R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". For example, a value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 link service request must wait for the response to that request. The fibre channel default value for R_A_TOV is 10 seconds.
R_A_TOVは[FC-FS]で「無くなっているフレームが骨組みから決して出て来ないのを保証する骨組みの中の最大のトランジット時間」と定義されます。 例えば、2x R_A_TOVの値はELS要求かFC-4リンクサービスのリクエストの創始者がその要求への応答を待たなければならない最小の時間です。 R_A_TOVのための繊維チャンネルデフォルト値は10秒です。
An iFCP gateway SHALL actively enforce limits on R_A_TOV as described in Section 8.2.1.
SHALLが活発に実施するiFCPゲートウェイはセクション8.2.1で説明されるようにR_Aで_TOVを制限します。
8.2.1. Enforcing R_A_TOV Limits
8.2.1. R_A_TOV限界を実施します。
The R_A_TOV limit on frame lifetimes SHALL be enforced by means of the time stamp in the encapsulation header (see Section 5.3.1) as described in this section.
R_A_TOVはカプセル化ヘッダーのタイムスタンプによって説明されるとして実施された(セクション5.3.1を見る)コネがこのセクションであったならフレームの上に生涯SHALLを制限します。
The budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs, plus the propagation delay through the IP network. This latter component is referred to in this specification as IP_TOV.
R_A_TOV SHOULDのための予算は送受信N_PORTsのゲートウェイ領域、およびIPネットワークを通した伝播遅延を通して伝播遅延のための小遣いを含んでいます。 この後者のコンポーネントはこの仕様にIP_TOVと呼ばれます。
IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV.
IP_TOVはiFCP骨組みに指定されたR_A_TOVの値の下でよく用意ができるべきであり、iSNSサーバで保存されるべきです。IP_TOVは50パーセントのR_A_TOVに用意ができるべきです。
The following paragraphs describe the requirements for synchronizing gateway time bases and the rules for measuring and enforcing propagation delay limits.
以下のパラグラフはゲートウェイ時間ベースを同期させるための要件と伝播遅れ限界を測定して、実施するための規則について説明します。
Monia, et al. Standards Track [Page 86] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[86ページ]RFC4172インターネット繊維チャンネル
The protocol for synchronizing a gateway time base is SNTP [RFC2030]. In order to ensure that all gateways are time aligned, a gateway SHOULD obtain the address of an SNTP-compatible time server via an iSNS query. If multiple time server addresses are returned by the query, the servers must be synchronized and the gateway may use any server in the list. Alternatively, the server may return a multicast group address in support of operation in Anycast mode. Implementation of Anycast mode is as specified in [RFC2030], including the precautions defined in that document. Multicast mode SHOULD NOT be used.
ゲートウェイ時間ベースを同期させるためのプロトコルはSNTP[RFC2030]です。 並べられて、すべてのゲートウェイが時間であることを確実にするために、ゲートウェイSHOULDはiSNS質問でSNTPコンパチブル時間サーバのアドレスを得ます。 質問で複数の時間サーバアドレスを返すなら、サーバを同期させなければなりません、そして、ゲートウェイはリストのどんなサーバも使用するかもしれません。 あるいはまた、サーバはAnycastモードにおける操作を支持してマルチキャストグループアドレスを返すかもしれません。 Anycastモードの実装がそのドキュメントで定義された注意を含む[RFC2030]で指定されるようにあります。 マルチキャストモードSHOULD NOT、使用されてください。
An SNTP server may use any one of the time reference sources listed in [RFC2030]. The resolution of the time reference MUST be 125 milliseconds or better.
SNTPサーバは[RFC2030]に記載された時間照合線源のいずれも使用するかもしれません。 時間参照の解決は、125ミリセカンドか、より良いに違いありません。
Stability of the SNTP server and gateway time bases should be 100 ppm or better.
SNTPサーバとゲートウェイ時間ベースの安定性は、100ppmか、より良いはずです。
With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state.
時間ベースに関して、ゲートウェイがSynchronizedかUnsynchronizedが述べるどちらかにあります。
When in the synchronized state, the gateway SHALL
連動している状態、ゲートウェイSHALLのいつ
a) set the time stamp field for each outgoing frame in accordance
with the gateway's internal time base;
a) ゲートウェイの内部の時間ベースに従って、それぞれの出発しているフレームにタイムスタンプ分野を設定してください。
b) check the time stamp field of each incoming frame, following
validation of the encapsulation header CRC, as described in
Section 5.3.4;
b) それぞれの入って来るフレームのタイムスタンプ分野をチェックしてください、カプセル化ヘッダーCRCの合法化に続いて、セクション5.3.4で説明されるように。
c) if the incoming frame has a time stamp of 0,0 and is not one of
the session control frames that require a 0,0 time stamp (see
Section 6), the frame SHALL be discarded;
c) 入来であるなら、フレームには0、0のタイムスタンプがあります、そして、捨てられて、1つが0を必要とするセッション制御フレーム、0タイムスタンプ(セクション6を見る)、フレームSHALLがありません。
d) if the incoming frame has a non-zero time stamp, the receiving
gateway SHALL compute the absolute value of the time in flight and
SHALL compare it against the value of IP_TOV specified for the IP
fabric;
d) 入って来るフレームに非ゼロタイムスタンプがあるなら、受信ゲートウェイSHALLは飛行での現代の絶対値を計算します、そして、SHALLはIP骨組みに指定されたIP_TOVの値に対してそれを比較します。
e) if the result in step (d) exceeds IP_TOV, the encapsulated frame
shall be discarded. Otherwise, the frame shall be de-encapsulated
as described in Section 5.3.4.
e) ステップ(d)における結果がIP_TOVを超えているなら、カプセル化されたフレームは捨てられるものとします。 さもなければ、フレームはセクション5.3.4で説明されるように反-カプセル化されるものとします。
A gateway SHALL enter the Synchronized state upon receiving a successful response to an SNTP query.
SHALLがSNTP質問へのうまくいっている応答を受けながらSynchronized状態に入るゲートウェイから。
Monia, et al. Standards Track [Page 87] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[87ページ]RFC4172インターネット繊維チャンネル
A gateway shall enter the Unsynchronized state:
ゲートウェイはUnsynchronized状態に入るものとします:
a) upon power-up and before successful completion of an SNTP query,
and
そしてa) パワーアップするのとSNTP質問の無事終了の前に。
b) whenever the gateway looses contact with the SNTP server, such
that the gateway's time base may no longer be in alignment with
that of the SNTP server. The criterion for determining loss of
contact is implementation specific.
b) ゲートウェイがほどけるときはいつも、接触の損失が実装特有であることを決定するためにSNTPサーバ(ゲートウェイの時間ベースが整列もうSNTPサーバのものがある中でないかもしれないようにもの)で評価基準に連絡してください。
Following loss of contact, it is recommended that the gateway enter the Unsynchronized state when the estimated time base drift relative to the SNTP reference is greater than ten percent of the IP_TOV limit. (Assuming that all timers have an accuracy of 100 ppm and IP_TOV equals 5 seconds, the maximum allowable loss of contact duration would be about 42 minutes.)
接触の損失に続いて、SNTP参照に比例したおよそ時間ベースドリフトがIP_TOV限界の10パーセント以上であるときに、ゲートウェイがUnsynchronized状態に入るのは、お勧めです。 (すべてのタイマには100ppmとIP_TOV同輩の精度が5秒あると仮定する場合、接触持続時間の最大の許容できる損失はおよそ42分でしょう。)
As the result of a transition from the Synchronized to the Unsynchronized state, a gateway MUST abort all iFCP sessions as described in Section 5.2.3. While in the Unsynchronized state, a gateway SHALL NOT permit the creation of new iFCP sessions.
SynchronizedからUnsynchronized状態までの変遷の結果として、ゲートウェイはセクション5.2.3で説明されるようにすべてのiFCPセッションに中止にならなければなりません。 Unsynchronized状態にある間、SHALL NOTが新しいiFCPセッションの作成を可能にするゲートウェイです。
9. Fabric Services Supported by an iFCP Implementation
9. iFCP実装で後押しされている骨組みのサービス
An iFCP gateway implementation MUST support the following fabric services:
iFCPゲートウェイ実装は、以下の骨組みがサービスであるとサポートしなければなりません:
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
N_ポートID値の記述部分--------------- ----------- ------- 0xFF ff FE F_ポートサーバ9.1
0xFF-FF-FD Fabric Controller 9.2
0xFF ff FD骨組みのコントローラ9.2
0xFF-FF-FC Directory/Name Server 9.3
0xFF ff FCディレクトリ/ネームサーバ9.3
In addition, an iFCP gateway MAY support the FC broadcast server functionality described in Section 9.4.
さらに、iFCPゲートウェイは、FC放送がセクション9.4で説明されたサーバの機能性であるとサポートするかもしれません。
9.1. F_PORT Server
9.1. F_ポートサーバ
The F_PORT server SHALL support the FLOGI ELS, as described in Section 7.4, as well as the following ELSs specified in [FC-FS]:
F_PORTサーバSHALLはFLOGI ELSをサポートします、セクション7.4、および[FC-FS]で指定された以下のELSsで説明されるように:
a) Request for fabric service parameters (FDISC).
a) 骨組みには、サービスパラメタ(FDISC)を要求してください。
b) Request for the link error status (RLS).
b) エラー状況(RLS)をリンクに要求してください。
c) Read Fabric Timeout Values (RTV).
c) 骨組みのタイムアウト値(RTV)を読んでください。
Monia, et al. Standards Track [Page 88] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[88ページ]RFC4172インターネット繊維チャンネル
9.2. Fabric Controller
9.2. 骨組みのコントローラ
The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]:
Fabric Controller SHALLは[FC-FS]の指定されるとしての以下のELSsをサポートします:
a) State Change Notification (SCN).
a) 変更届出書(SCN)を述べてください。
b) Registered State Change Notification (RSCN).
b) 登録された州の変更届出書(RSCN)。
c) State Change Registration (SCR).
c) 変化登録(SCR)を述べてください。
9.3. Directory/Name Server
9.3. ディレクトリ/ネームサーバ
The Directory/Name server provides a registration service allowing an N_PORT to record or query the database for information about other N_PORTs. The services are defined in [FC-GS3]. The queries are issued as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3].
ディレクトリ/ネームサーバはN_PORTが他のN_PORTsの情報のためのデータベースについて記録するか、または質問する登録サービスを、提供します。 サービスは[FC-GS3]で定義されます。 FC-コネチカットコマンドトランスポート・プロトコルを使用するFC-4トランザクションが[FC-GS3]で指定したように質問は発行されます。
In iFCP, each name server request MUST be translated to the appropriate iSNS query defined in [ISNS]. The definitions of name server objects are specified in [FC-GS3].
iFCPでは、[ISNS]で定義された適切なiSNS質問にそれぞれのネームサーバ要求を翻訳しなければなりません。 ネームサーバオブジェクトの定義は[FC-GS3]で指定されます。
The name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and MAY support the FC-4 specific services as defined in [FC-GS3].
ディレクトリ「副-タイプ」0×02(名前Server)と0x03(IP Address Server)と5月のためのネームサーバSHALLサポート記録と質問操作は[FC-GS3]で定義されるようにFC-4の特定のサービスをサポートします。
9.4. Broadcast Server
9.4. 放送サーバ
Fibre channel frames are broadcast throughout the fabric by addressing them to the fibre channel broadcast server at the well- known fibre channel address 0xFF-FF-FF. The broadcast server then replicates and delivers the frame to each attached N_PORT in all zones to which the originating device belongs. Only class 3 (datagram) service is supported.
よく知られている繊維チャンネルアドレス0xFF-FF-FFで繊維チャンネル放送サーバにそれらを扱うのによる骨組みの間中繊維チャンネルフレームは放送です。 次に、放送サーバは、起因するデバイスが属するすべてのゾーンのそれぞれの付属N_PORTにフレームを模写して、提供します。 クラス3(データグラム)サービスだけがサポートされます。
In an iFCP system, the fibre channel broadcast function is emulated by means of a two-tier architecture comprising the following elements:
iFCPシステムでは、繊維チャンネル放送機能は以下の要素を包括する2層のアーキテクチャによって見習われます:
a) A local broadcast server residing in each iFCP gateway. The local
server distributes broadcast traffic within the gateway region and
forwards outgoing broadcast traffic to a global server for
distribution throughout the iFCP fabric.
a) それぞれのiFCPゲートウェイにあるローカル放送サーバ。 ローカルサーバは、ゲートウェイ領域の中で放送トラフィックを分配して、iFCP骨組みの間中分配のためのグローバルなサーバに外向的な放送トラフィックを送ります。
b) A global broadcast server that re-distributes broadcast traffic to
the local server in each participating gateway.
b) それが再配付するグローバルな放送サーバはそれぞれの参加ゲートウェイのローカルサーバにトラフィックを放送しました。
Monia, et al. Standards Track [Page 89] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[89ページ]RFC4172インターネット繊維チャンネル
c) An iSNS discovery domain defining the scope over which broadcast
traffic is propagated. The discovery domain is populated with a
global broadcast server and the set of local servers it supports.
c) どの放送トラフィックの上で範囲を決めるiSNS発見ドメインは伝播されます。 発見ドメインはグローバルな放送サーバとそれがサポートするローカルサーバのセットで居住されます。
The local and global broadcast servers are logical iFCP devices that communicate using the iFCP protocol. The servers have an N_PORT Network Address consisting of an iFCP portal address and an N_PORT ID set to the well-known fibre channel address of the FC broadcast server (0xFF-FF-FF).
地方の、そして、グローバルな放送サーバはiFCPプロトコルを使用することで交信する論理的なiFCPデバイスです。 サーバで、iFCP入り口のアドレスから成るN_PORT Network AddressとN_PORT IDをFC放送サーバ(0xFF-FF-FF)のよく知られる繊維チャンネル・アドレスに用意ができさせます。
As noted above, an N_PORT originates a broadcast by directing frame traffic to the fibre channel broadcast server. The gateway-resident local server distributes a copy of the frame locally and forwards a copy to the global server for redistribution to the local servers on other gateways. The global server MUST NOT echo a broadcast frame to the originating local server.
上で述べたように、N_PORTは、繊維チャンネル放送サーバにフレームトラフィックを向けることによって、放送を溯源します。ゲートウェイ居住者ローカルサーバは、他のゲートウェイの上のローカルサーバへの再分配のために局所的にフレームのコピーを分配して、グローバルなサーバにコピーを送ります。 グローバルなサーバは起因するローカルサーバに放送フレームを反響してはいけません。
9.4.1. Establishing the Broadcast Configuration
9.4.1. 放送構成を確立します。
The broadcast configuration is managed with facilities provided by the iSNS server by the following means:
放送構成はiSNSサーバで以下の手段で施設を提供している状態で管理されます:
a) An iSNS discovery domain is created and seeded with the network
address of the global broadcast server N_PORT. The global server
is identified as such by setting the appropriate N_PORT entity
attribute.
a) iSNS発見ドメインは、グローバルな放送サーバN_PORTのネットワーク・アドレスで作成されて、種を蒔かれます。 グローバルなサーバは、適切なN_PORT実体属性を設定しながら、そういうものとして身元を確認されます。
b) Using the management interface, each broadcast server is preset
with the identity of the broadcast domain.
b) 管理インタフェースを使用して、それぞれの放送サーバは放送ドメインのアイデンティティであらかじめセットされます。
During power up, each gateway SHALL invoke the iSNS service to register its local broadcast server in the broadcast discovery domain. After registration, the local server SHALL wait for the global broadcast server to establish an iFCP session.
パワーアップの間、各ゲートウェイSHALLは、放送発見ドメインにローカル放送サーバを登録するためにiSNSサービスを呼び出します。 登録の後に、ローカルサーバSHALLは、グローバルな放送サーバがiFCPセッションを確立するのを待ちます。
The global server SHALL register with the iSNS server as follows:
グローバルなサーバSHALLは以下のiSNSサーバとともに記名します:
a) The server SHALL query the iSNS name server by attribute to obtain
the worldwide port name of the N_PORT pre-configured to provide
global broadcast services.
a) サーバSHALLは、世界的なポート名(グローバルな放送サービスを提供するためにあらかじめ設定されたN_PORT)を得るために属性でiSNSネームサーバについて質問します。
b) If the worldwide port name obtained above does not correspond to
that of the server issuing the query, the N_PORT SHALL NOT perform
global broadcast functions for N_PORTs in that discovery domain.
b) 上で得られた世界的なポート名が質問を発行するサーバのものと食い違っているなら、N_PORT SHALL NOTはN_PORTsのためにその発見ドメインでグローバルな放送機能を実行します。
c) Otherwise, the global server N_PORT SHALL register with the
discovery domain and query the iSNS server to identify all
currently registered local servers.
c) さもなければ、グローバルなサーバN_PORT SHALLは、すべての現在登録されたローカルサーバを特定するために発見ドメインとともに記名して、iSNSサーバについて質問します。
Monia, et al. Standards Track [Page 90] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[90ページ]RFC4172インターネット繊維チャンネル
d) The global broadcast server SHALL initiate an iFCP session with
each local broadcast server in the domain. When a new local
server registers, the global server SHALL receive a state change
notification and respond by initiating an iFCP session with the
newly added server. The gateway SHALL obtain these notifications
using the iSNS provisions for lossless delivery.
d) グローバルな放送サーバSHALLはそのドメインのそれぞれのローカル放送サーバとのiFCPセッションを開始します。 新しいローカルサーバが登録されるとき、グローバルなサーバSHALLは、新たに加えられたサーバで、州の変更届出書を受け取って、iFCPセッションを開始することによって、応じます。ゲートウェイSHALLは、lossless配送にiSNS条項を使用することでこれらの通知を得ます。
Upon receiving the CBIND request to initiate the iFCP session, the local server SHALL record the worldwide port name and N_PORT network address of the global server.
CBINDがiFCPセッションを開始するよう要求する受信に、ローカルサーバSHALLはグローバルなサーバの世界的なポート名とN_PORTネットワーク・アドレスを記録します。
9.4.2. Broadcast Session Management
9.4.2. 放送セッション管理
After the initial broadcast session is established, the local or global broadcast server MAY choose to manage the session in one of the following ways, depending on resource requirements and the anticipated level of broadcast traffic:
初期の放送セッションが確立された後に、地方の、または、グローバルな放送サーバは、以下の方法の1つでセッションを管理するのを選ぶかもしれません、リソース要件と予期されたレベルの放送トラフィックによって:
a) A server MAY keep the session open continuously. Since broadcast
sessions are often quiescent for long periods of time, the server
SHOULD monitor session connectivity as described in Section
5.2.2.4.
a) サーバは絶え間なくセッションを開くように保つかもしれません。 以来放送されたセッションは長期間の間、しばしば静かであり、セクション5.2.2における説明されるとしてのサーバSHOULDモニターセッションの接続性は.4です。
b) A server MAY open the broadcast session on demand only when
broadcast traffic is to be sent. If the session is reopened by
the global server, the local server SHALL replace the previously
recorded network address of the global broadcast server.
b) サーバは送られる放送トラフィックがことであるオンデマンドの放送セッションだけを開くかもしれません。 セッションはグローバルなサーバによって再開させられるなら、ローカルサーバSHALLがグローバルな放送サーバの以前に記録されたネットワーク・アドレスを置き換えます。
9.4.3. Standby Global Broadcast Server
9.4.3. 待機のグローバルな放送サーバ
An implementation may designate a local server to assume the duties of the global broadcast server in the event of a failure. The local server may use the LTEST message to determine whether the global server is functioning and may assume control if it is not.
実装は、失敗の場合、グローバルな放送サーバの義務を引き受けるためにローカルサーバを指定するかもしれません。 ローカルサーバは、グローバルなサーバが機能しているかどうか決定するLTESTメッセージを使用して、それが仮定しないなら、コントロールを仮定するかもしれません。
When assuming control, the standby server must register with the iSNS server as the global broadcast server in place of the failed server and must install itself in the broadcast discovery domain as specified in steps c) and d) of Section 9.4.1.
コントロールを仮定すると、待機サーバは、グローバルな放送サーバとして失敗したサーバに代わってiSNSサーバとともに記名しなければならなくて、セクション9.4.1のステップc)とd)における指定されるとしての放送発見ドメインにそれ自体をインストールしなければなりません。
10. iFCP Security
10. iFCPセキュリティ
10.1. Overview
10.1. 概要
iFCP relies upon the IPSec protocol suite to provide data confidentiality and authentication services, and it relies upon IKE as the key management protocol. Section 10.2 describes the security requirements arising from iFCP's operating environment, and Section
iFCPはデータの機密性と認証サービスを提供するためにIPSecプロトコル群を当てにします、そして、かぎ管理が議定書を作るとき、それはIKEを当てにされます。 セクション10.2はiFCPの操作環境、およびセクションから起こるセキュリティ要件について説明します。
Monia, et al. Standards Track [Page 91] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[91ページ]RFC4172インターネット繊維チャンネル
10.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol.
10.3結果として起こるデザイン選択と、自己の要件レベルと、それらがどう適用するかをiFCPプロトコルに説明します。
Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS].
[SECIPS]でiFCPプロトコルがあるIPsecとIKEの使用のための詳細な問題を見つけることができます。
10.2. iFCP Security Threats and Scope
10.2. iFCP軍事的脅威と範囲
10.2.1. Context
10.2.1. 文脈
iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may have to traverse security gateways in order to support SAN-to-SAN connectivity across public networks.
iFCPは使用のために企業データセンターで配布されたゲートウェイデバイスによって設計されたプロトコルです。 そのような環境で、分離を通して公衆通信回線からネットワークセキュリティを提供するようにセキュリティゲートウェイを通常設計します。 その上、iFCPデータは、公衆通信回線の向こう側にSANからSANが接続性であるとサポートするためにセキュリティゲートウェイを横断しなければならないかもしれません。
10.2.2. Security Threats
10.2.2. 軍事的脅威
Communicating iFCP gateways may be subjected to attacks, including attempts by an adversary to:
iFCPゲートウェイを伝えるのは以下のことのために敵による試みを含む攻撃にかけられるかもしれません。
a) acquire confidential data and identities by snooping data packets,
a) データ・パケットについて詮索することによって、秘密のデータとアイデンティティを取得してください。
b) modify packets containing iFCP data and control messages,
b) iFCPデータとコントロールメッセージを含むパケットを変更してください。
c) inject new packets into the iFCP session,
c) iFCPセッションに新しいパケットを注いでください。
d) hijack the TCP connection carrying the iFCP session,
d) iFCPセッションを運ぶTCP接続をハイジャックしてください。
e) launch denial-of-service attacks against the iFCP gateway,
e) iFCPゲートウェイに対してサービス不能攻撃に着手してください。
f) disrupt the security negotiation process,
f) セキュリティ交渉プロセスを混乱させてください。
g) impersonate a legitimate security gateway, or
またはg) 正統のセキュリティゲートウェイをまねてください。
h) compromise communication with the iSNS server.
h) iSNSサーバとのコミュニケーションに感染してください。
It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole fibre channel island, which may include several hosts and fibre channel switches. To do so, the iFCP gateway must implement and may use confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. The iFCP gateway must implement and may use bi-directional authentication of the communication endpoints. Finally, it must implement and may use a scalable approach to key management.
これらの攻撃を阻むのは必須です、iFCPゲートウェイが全体の繊維チャンネル島(数人のホストと繊維チャンネルスイッチを含むかもしれない)への最後の砦であるなら。 iFCPゲートウェイは、そうするのに、実装しなければならなくて、1データグラムあたり1個のベースで秘密性、データ発生源認証、保全、および反復操作による保護を使用するかもしれません。 iFCPゲートウェイは、実装しなければならなくて、コミュニケーション終点の双方向の認証を使用するかもしれません。 最終的に、それは、実装しなければならなくて、かぎ管理へのスケーラブルなアプローチを使用するかもしれません。
Monia, et al. Standards Track [Page 92] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[92ページ]RFC4172インターネット繊維チャンネル
10.2.3. Interoperability with Security Gateways
10.2.3. セキュリティゲートウェイがある相互運用性
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which, at a minimum, provide a shield against denial-of- service attacks. The iFCP security architecture is capable of leveraging the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways. Considerations regarding intervening NAT and NAPT boxes along the iFCP-iSNS path can be found in [ISNS].
エンタープライズデータセンターネットワークは、隔離しなければならないミッションクリティカルな施設であると考えられて、すべての可能な軍事的脅威から保護されます。 通常、そのようなネットワークが最小限で否定に対してシールドを提供するセキュリティゲートウェイによって保護される、-、サービス攻撃について。 iFCPセキュリティー体系は既存のセキュリティインフラストラクチャの保護的なサービスを利用することができます、既存のセキュリティゲートウェイで利用可能なファイアウォール保護、NAT、NAPTサービス、およびIPSec VPNサービスを含んでいて。 [ISNS]で介入しているNATに関する問題とiFCP-iSNS経路に沿ったNAPT箱を見つけることができます。
10.2.4. Authentication
10.2.4. 認証
iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either peer gateway or both. Consequently, bi-directional authentication of peer gateways must be provided in accordance with the requirement levels specified in Section 10.3.1.
iFCPはピアツーピアプロトコルです。iFCPセッションは同輩ゲートウェイか両方のどちらかによって開始されるかもしれません。 その結果、セクション10.3.1で指定された要件レベルに応じて、同輩ゲートウェイの双方向の認証を提供しなければなりません。
N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated if the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection.
リモートゲートウェイからPLOGI要求を安全で、IPSecによって保護された接続の上に受け取るなら、認証されているとPort Login(PLOGI)プロセスで使用されるN_PORTのアイデンティティを考えるものとします。
There is no requirement that the identities used in authentication be kept confidential.
認証に使用されるアイデンティティが秘密にされるという要件が全くありません。
10.2.5. Confidentiality
10.2.5. 秘密性
iFCP traffic may traverse insecure public networks, and therefore implementations must have per-packet encryption capabilities to provide confidentiality in accordance with the requirements specified in Section 10.3.1.
iFCPトラフィックは不安定な公衆通信回線を横断するかもしれません、そして、したがって、実装には、セクション10.3.1で指定された要件に応じて秘密性を提供する1パケットあたりの暗号化能力がなければなりません。
10.2.6. Rekeying
10.2.6. Rekeyingします。
Due to the high data transfer rates and the amount of data involved, an iFCP implementation must support the capability to rekey each phase 2 security association in the time intervals dictated by sequence number space exhaustion at a given link rate. In the rekeying scenario described in [SECIPS], for example, rekeying events happen as often as every 27.5 seconds at a 10 Gbps rate.
高いデータ転送速度とかかわったデータ量のため、iFCP実装は、rekeyへの能力が時間間隔の2セキュリティ協会が与えられたリンクレートで一連番号宇宙疲労困憊で書き取った各フェーズであるとサポートしなければなりません。 イベントを「再-合わせ」る例えば[SECIPS]で説明された「再-合わせ」ているシナリオでは、10Gbpsの27.5秒毎が評価するのと同じくらい頻繁に起こってください。
The iFCP gateway must provide the capability for forward secrecy in the rekeying process.
iFCPゲートウェイは「再-合わせ」るプロセスの前進の秘密保持に能力を提供しなければなりません。
Monia, et al. Standards Track [Page 93] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[93ページ]RFC4172インターネット繊維チャンネル
10.2.7. Authorization
10.2.7. 承認
Basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and certificate-based authentication (e.g., with X509v3 certificates) enables authorization schemas of increasing complexity. The definition of such schemas (e.g., role-based access control) is outside of the scope of this specification.
基本的なアクセス制御の特性はiFCP交換に従事できる前に交信している2iFCP門が1つ以上のiSNSサーバに知られているという要件によります。 発見ドメイン[ISNS]、Identity有効搭載量(例えば、ID_FQDNs)、および証明書ベースの認証(例えば、X509v3証明書がある)の任意の使用は増加する複雑さの承認schemasを有効にします。 そのようなschemas(例えば、役割のベースのアクセスコントロール)の定義がこの仕様の範囲の外にあります。
10.2.8. Policy Control
10.2.8. 方針コントロール
This specification allows any and all security mechanisms in an iFCP gateway to be administratively disabled. Security policies MUST have, at most, iFCP Portal resolution. Administrators may gain control over security policies through an adequately secured interaction with a management interface or with iSNS.
この仕様は、iFCPゲートウェイのありとあらゆるセキュリティー対策が行政上無効にされるのを許容します。 安全保障政策は大部分にiFCP Portal解決を持たなければなりません。 管理者は管理インタフェースかiSNSとの適切に機密保護している相互作用で安全保障政策のコントロールを獲得するかもしれません。
10.2.9. iSNS Role
10.2.9. iSNSの役割
iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways MUST use iSNS for discovery services and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms for securing communication between an iFCP gateway and iSNS server(s). Additionally, the specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s).
iSNS[ISNS]はすべてのiFCP展開で不変式です。iFCPゲートウェイは、発見サービスにiSNSを使用しなければならなくて、アルゴリズム交渉にIKEで基礎としてiSNSデータベースで構成された安全保障政策を使用するかもしれません。 iSNS仕様は、iFCPゲートウェイとiSNSサーバとのコミュニケーションを保証するためにメカニズムを定義します。 さらに、仕様はiSNSサーバから個々のiFCPセッションに関する安全保障政策の要素をどう検索できるかを示します。
10.3. iFCP Security Design
10.3. iFCPセキュリティデザイン
10.3.1. Enabling Technologies
10.3.1. 技術を可能にします。
Applicable technology from IPsec and IKE is defined in the following suite of specifications:
IPsecとIKEからの適切な技術は仕様の以下のスイートで定義されます:
[RFC2401] Security Architecture for the Internet Protocol
インターネットプロトコルのための[RFC2401]セキュリティー体系
[RFC2402] IP Authentication Header
[RFC2402]IP認証ヘッダー
[RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH
そして、超能力の中のHMAC-SHA-1-96の[RFC2404]使用、ああ。
[RFC2405] The ESP DES-CBC Cipher Algorithm with Explicit IV
[RFC2405] 明白なIVがある超能力DES-CBC暗号アルゴリズム
[RFC2406] IP Encapsulating Security Payload
セキュリティが有効搭載量であるとカプセル化する[RFC2406]IP
Monia, et al. Standards Track [Page 94] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[94ページ]RFC4172インターネット繊維チャンネル
[RFC2407] The Internet IP Security Domain of Interpretation for
ISAKMP
[RFC2407] ISAKMPのための解釈のインターネットIPセキュリティー領域
[RFC2408] Internet Security Association and Key Management
Protocol (ISAKMP)
[RFC2408]インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)
[RFC2409] The Internet Key Exchange (IKE)
[RFC2409] インターネット・キー・エクスチェンジ(イケ)
[RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
[RFC2410] ヌル暗号化アルゴリズムとIPSECとのその使用
[RFC2451] The ESP CBC-Mode Cipher Algorithms
[RFC2451] 超能力CBC-モード暗号アルゴリズム
[RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
NATドメインへのトンネルモードIPsecの[RFC2709]機密保護モデル
The implementation of IPsec and IKE is required according to the following guidelines.
以下のガイドラインによると、IPsecとIKEの実装が必要です。
Support for the IP Encapsulating Security Payload (ESP) [RFC2406] is MANDATORY to implement. When ESP is used, per-packet data origin authentication, integrity, and replay protection MUST be used.
IP Encapsulating Security有効搭載量(超能力)[RFC2406]のサポートは道具へのMANDATORYです。 超能力が使用されているとき、1パケットあたりのデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
For data origin authentication and integrity with ESP, HMAC with SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining SHOULD be implemented in accordance with [AESCBC].
超能力に伴うデータ発生源認証と保全、[RFC2404]を実装しなければならないSHA1とHMAC、およびExtended Cipher Block Chaining SHOULDがあるCBC MACモードによるエー・イー・エス[AES]のために、[AESCBC]に従って、実装されてください。
For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be implemented, and AES counter mode encryption [AESCTR] SHOULD be implemented. NULL encryption MUST be supported as well, as defined in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its inherent weakness. Since it is known to be crackable with modest computation resources, it is inappropriate for use in any iFCP deployment scenario.
超能力、モード[RFC2451]を実装しなければならないCBCの3DES、およびAESカウンタモード暗号化[AESCTR]SHOULDがある秘密性に関しては、実装されてください。 また、[RFC2410]で定義されるようにNULL暗号化をサポートしなければなりません。 DES、CBCモードSHOULD NOTで、固有の弱点のため使用されてください。 穏やかな計算リソースで「割-可能」であることが知られているので、どんなiFCP展開シナリオでも使用に、それは不適当です。
A conforming iFCP protocol implementation MUST implement IPsec ESP [RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in transport mode.
従っているiFCPプロトコル実装は、トンネルモード[RFC2401]でIPsecが超能力[RFC2406]であると実装しなければならなくて、IPsecが超能力であると交通機関で実装するかもしれません。
Regarding key management, iFCP implementations MUST support IKE [RFC2409] for bi-directional peer authentication, negotiation of security associations, and key management, using the IPsec DOI. There is no requirement that the identities used in authentication be kept confidential. Manual keying MUST NOT be used since it does not provide the necessary keying support. According to [RFC2409], pre- shared secret key authentication is MANDATORY to implement, whereas certificate-based peer authentication using digital signatures MAY be implemented (see Section 10.3.3 regarding the use of certificates). [RFC2409] defines the following requirement levels for IKE Modes:
かぎ管理に関して、iFCP実装は、IKEが双方向の同輩認証のための[RFC2409]と、セキュリティ協会の交渉と、かぎ管理であるとサポートしなければなりません、IPsec DOIを使用して。 認証に使用されるアイデンティティが秘密にされるという要件が全くありません。 サポートを合わせながら金策しないので、手動の合わせることを使用してはいけません。 [RFC2409]に従って、プレ共有秘密キーの主要な認証は道具へのMANDATORYですが、デジタル署名を使用する証明書ベースの同輩認証は実装されるかもしれません(証明書の使用に関してセクション10.3.3を見てください)。 [RFC2409]はIKE Modesのために以下の要件レベルを定義します:
Monia, et al. Standards Track [Page 95] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[95ページ]RFC4172インターネット繊維チャンネル
Phase-1 Main Mode MUST be implemented.
フェーズ-1Main Modeを実装しなければなりません。
Phase-1 Aggressive Mode SHOULD be implemented.
フェーズ-1Aggressive Mode SHOULD、実装されてください。
Phase-2 Quick Mode MUST be implemented.
フェーズ-2クィックModeを実装しなければなりません。
Phase-2 Quick Mode with key exchange payload MUST be implemented.
主要な交換ペイロードがあるフェーズ-2クィックModeを実装しなければなりません。
With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with pre-shared keys, due to Main Mode's vulnerability to man-in-the- middle-attackers when group pre-shared keys are used. In this scenario, Aggressive Mode SHOULD be used instead. Peer authentication using the public key encryption methods outlined in [RFC2409] SHOULD NOT be used.
iFCP、Phase-1 Main Mode SHOULD、あらかじめ共有されたキーに関連して使用されないでください、中の男性へのMain Modeの脆弱性のため-、-グループがキーをあらかじめ共有したとき、真ん中の攻撃者は使用されています。 このシナリオ、Aggressive Mode SHOULD、代わりに使用されてください。 公開鍵暗号化メソッドを使用する同輩認証が[RFC2409]にSHOULD NOTについて概説しました。使用されます。
The DOI [RFC2407] provides for several types of Identification Payloads.
DOI[RFC2407]はいくつかのタイプのIdentification有効搭載量に備えます。
When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conforming iFCP implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), or ID_FQDN Identification Type values. The ID_USER_FQDN, IP Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN Identification Type values SHOULD NOT be used. The ID_KEY_ID Identification Type values MUST NOT be used. As described in [RFC2407], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
iFCPに使用されると、IKE Phase1交換は明らかに、Identification有効搭載量野原(IDiiとIDir)を運ばなければなりません。 iFCP実装を従わせると、__ID IPV4_ADDR、ID IPV6_ADDR(プロトコル・スタックがIPv6をサポートするなら)、またはID_FQDN Identification Type値が使用されなければなりません。 _ID USER_FQDN、IP Subnet、IP Address Range、ID_DER_ASN1__DN、ID DER_ASN1_GN Identification TypeはSHOULD NOTを評価します。使用されます。 ID_KEY_ID Identification Type値を使用してはいけません。 [RFC2407]で説明されるように、Identification有効搭載量におけるポートとプロトコル分野はゼロへのセットであるに違いありませんかUDPが500を移植します。
When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the Identification Payload fields (IDci and IDcr). Conforming iFCP implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (according to the version of IP supported). Other Identification Type values MUST NOT be used. As described in Section 5.2.2, the gateway creating the iFCP session must query the iSNS server to determine the appropriate port on which to initiate the associated TCP connection. Upon a successful IKE Phase 2 exchange, the IKE responder enforces the negotiated selectors on the IPsec SAs. Any subsequent iFCP session creation requires the iFCP peer to query its iSNS server for access control (in accordance with the session creation requirements specified in Section 5.2.2.1).
iFCPに使用されると、IKE Phase2交換は明らかに、Identification有効搭載量野原(IDciとIDcr)を運ばなければなりません。 iFCP実装を従わせると、IPV4_ADDRかID_IPV6_ADDR Identification Typeが評価する(IPのバージョンによると、サポートされます)ID_は使用されなければなりません。 他のIdentification Type値を使用してはいけません。 セクション5.2.2で説明されるように、iFCPセッションを作成するゲートウェイは関連TCP接続を開始する適切なポートを決定するためにiSNSサーバについて質問しなければなりません。 うまくいっているIKE Phase2交換のときに、IKE応答者は交渉されたセレクタにIPsec SAsに押しつけます。 どんなその後のiFCPセッション作成も、iFCP同輩がアクセスコントロールのためのiSNSサーバについて質問するのを必要とします(セッション作成に従って、要件はセクション5.2.2で.1を指定しました)。
10.3.2. Use of IKE and IPsec
10.3.2. IKEとIPsecの使用
A conforming iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized or may be deferred until the first TCP connection with security requirements is established.
従うiFCP Portalは1IKE Phase-1 Security Associations(SAs)を同輩iFCP Portalに設立できます。 セキュリティ要件との最初のTCP関係が確立されるまで、iFCP Portalが初期化されるか、または延期されるとき、Phase-1 SAは確立しているかもしれません。
Monia, et al. Standards Track [Page 96] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[96ページ]RFC4172インターネット繊維チャンネル
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, the successful establishment of an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <SPI, destination IP address, ESP>.
IKE Phase-2 SAは同じiFCP Portalの中の1つ以上のTCP接続を保護します。 より明確に、IKE Phase-2 SAのうまくいっている設立は完全にtuple<SPIによって資格があった2uni方向のIPsec SAsの作成をもたらします、送付先IPアドレス、超能力>。
These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. The number of TCP connections in an IPsec SA, as well as the number of SAs, is practically driven by security policy considerations (i.e., security services are defined at the granularity of an IPsec SA only), QoS considerations (e.g., multiple QoS classes within the same IPsec SA increase odds of packet reordering, possibly falling outside the replay window), and failure compartmentalization considerations. Each of the TCP connections protected by an IPsec SA is either in the unbound state, or bound to a specific iFCP session.
これらのSAsは基本的なTCP接続と彼らのすべてのその後のTCPトラフィックのセットアッププロセスを保護します。 IPsec SAのTCP接続の数、およびSAsの数は安全保障政策問題(すなわち、セキュリティー・サービスはIPsec SAの粒状だけで定義される)、QoS問題(例えば、同じIPsec SAの中の複数のQoSのクラスがパケット再命令の可能性を増強します、ことによると再生ウィンドウをそらせて)、および失敗区画化問題で実際にやる気満々です。 IPsec SAによって保護されたTCP接続各人は、どちらか無限の状態にいるか、または特定のiFCPセッションまで縛られます。
In summary, at any point in time:
概要では、いずれも、時間内に、指してください:
-- there exist 0..M IKE Phase-1 SAs between peer iFCP portals,
-- 0は存在しています。同輩iFCP入り口の間のM IKE Phase-1 SAs
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
-- 各IKE Phase-1 SAには、0があります。そしてN IKEフェーズ-2SAs。
-- each IKE Phase-2 SA protects 0..Z TCP connections.
-- 各IKE Phase-2 SAは0を保護します。Z TCP接続。
The creation of an IKE Phase-2 SA may be triggered by a policy rule supplied through a management interface or by iFCP Portal properties registered with the iSNS server. Similarly, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface or by an iFCP Portal policy rule registered with the iSNS server.
IKE Phase-2 SAの作成は管理インタフェースを通して供給された政策ルールかiSNSサーバに示されたiFCP Portalの特性によって引き起こされるかもしれません。同様に、クィックModeにおける、Key Exchangeペイロードの完全な前進の秘密保持の使用は管理インタフェースを通して、または、iSNSサーバに登録されたiFCP Portal政策ルールで書き取られるかもしれません。
If an iFCP implementation makes use of unbound TCP connections, and such connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times just like bound connections.
iFCP実装が無限のTCP接続を利用して、そのような接続がセキュリティ要件があるiFCP Portalに属すなら、SAはまさしく制限された接続のようにいつも無限の接続を保護しなければなりません。
Upon receipt of an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating these connections might in fact be inappropriate and untimely.
IKE Phase-2を受け取り次第、メッセージを削除するか、保護されたTCP接続を終えるという要件が全くないか、または関連IKE Phase-1 SAを削除してください。 IKE Phase-2 SAが複数のTCP接続に関連しているかもしれないので、事実上、これらの接続を終えるのは、不適当であって、タイミングが悪いかもしれません。
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA
アクティブなPhase-2 SAs、IKE Phase-2の数を最小にするために、メッセージを削除してください。TCP接続がしばらくデータ通信量を扱っていないPhase-2 SAsのために送ってもよいです。 SAの使用を最小にするために
Monia, et al. Standards Track [Page 97] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[97ページ]RFC4172インターネット繊維チャンネル
resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.
リソースが関連TCP接続である間、無駄である、新しいSAの作成は接続の上に送るまで新しいデータがことである延期されるべきです。
10.3.3. Signatures and Certificate-Based Authentication
10.3.3. 署名と証明書ベースの認証
Conforming iFCP implementations MAY support peer authentication via digital signatures and certificates. When certificate authentication is chosen within IKE, each iFCP gateway needs the certificate credentials of each peer iFCP gateway in order to establish a security association with that peer.
iFCP実装を従わせると、デジタル署名を通した同輩認証と証明書は支えられるかもしれません。 証明書認証がIKEの中で選ばれていると、それぞれのiFCPゲートウェイは、その同輩とのセキュリティ仲間を設立するためにそれぞれの同輩iFCPゲートウェイの証明書資格証明書を必要とします。
Certificate credentials used by iFCP gateways MUST be those of the machine. Certificate credentials MAY be bound to the interface (IP Address or FQDN) of the iFCP gateway used for the iFCP session, or to the fabric WWN of the iFCP gateway itself. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. User certificates SHOULD NOT be used by iFCP gateways for establishment of SAs protecting iFCP sessions.
iFCPゲートウェイによって使用される証明書資格証明書はマシンのものであるに違いありません。 証明書資格証明書はiFCPセッションに使用されるiFCPゲートウェイのインタフェース(IP AddressかFQDN)、または、iFCPゲートウェイ自体の骨組みのWWNに縛られるかもしれません。 マシン証明書の値が逆に攻撃者が偽って1つを得ることができる容易さに変化しているので、マシン証明書登録プロセスが厳密に制御されるのは、賢明です。 例えば、管理者だけには、マシン証明書でマシンを登録する能力があるかもしれません。 ユーザはSHOULD NOTを証明します。iFCPゲートウェイで、SAsの設立にiFCPセッションを保護しながら、使用されてください。
If the gateway does not have the peer iFCP gateway's certificate credentials, then it can obtain them:
ゲートウェイに同輩iFCPゲートウェイの証明書資格証明書がないなら、それらを得ることができます:
a) by using the iSNS protocol to query for the peer gateway's
certificate(s) stored in a trusted iSNS server, or
またはa) 同輩ゲートウェイのものに質問するiSNSプロトコルを使用することによって、信じられたiSNSサーバで保存された(s)を証明してください。
b) through use of the ISAKMP Certificate Request Payload (CRP)
[RFC2408] to request the certificate(s) directly from the peer
iFCP gateway.
ISAKMP Certificate Request有効搭載量(CRP)の使用によるb) [RFC2408] 直接同輩iFCPゲートウェイから証明書を要求するために。
When certificate chains are long enough, IKE exchanges using UDP as the underlying transport may yield IP fragments, which are known to work poorly across some intervening routers, firewalls, and NA(P)T boxes. As a result, the endpoints may be unable to establish an IPsec security association.
証明書チェーンが十分長いときに、基本的な輸送としてUDPを使用するIKE交換はIP断片をもたらすかもしれません。(断片はいくつかの介入しているルータ、ファイアウォール、およびNA(P)T箱の向こう側に不十分に働くのが知られています)。 その結果、終点はIPsecセキュリティ協会を設立できないかもしれません。
Due to these fragmentation shortcomings, IKE is most appropriate for intra-domain usage. Known solutions to the fragmentation problem include sending the end-entry machine certificate rather than the chain, reducing the size of the certificate chain, using IKE implementations over a reliable transport protocol (e.g., TCP) assisted by Path MTU discovery and code against black-holing as per [RFC2923], or installing network components that can properly handle fragments.
これらの断片化短所のために、イントラドメイン用法に、IKEは最も適切です。 断片化問題への知られている解決は、チェーンよりむしろ端エントリーマシン証明書を送るのを含んでいます、証明書チェーンのサイズを減少させて、[RFC2923]に従って黒を掘らないようにPath MTU発見とコードによって補助されるか、または適切に断片を扱うことができるネットワーク要素をインストールしながら信頼できるトランスポート・プロトコル(例えば、TCP)の上でIKE実装を使用して。
Monia, et al. Standards Track [Page 98] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[98ページ]RFC4172インターネット繊維チャンネル
IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) [RFC2408] before accepting a certificate for use in IKE's authentication procedures.
証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)[RFC2408]をチェックします。
10.4. iSNS and iFCP Security
10.4. iSNSとiFCPセキュリティ
iFCP implementations MUST use iSNS for discovery and management services. Consequently, the security of the iSNS protocol has an impact on the security of iFCP gateways. For a discussion of potential threats to iFCP gateways through use of iSNS, see [ISNS].
iFCP実装は発見と経営指導にiSNSを使用しなければなりません。 その結果、iSNSプロトコルのセキュリティはiFCPゲートウェイのセキュリティに影響を与えます。 iSNSの使用によるiFCPゲートウェイへの潜在的な脅威の議論に関しては、[ISNS]を見てください。
To provide security for iFCP gateways using the iSNS protocol for discovery and management services, the IPSec ESP protocol in tunnel mode MUST be supported for iFCP gateways. Further discussion of iSNS security implementation requirements is found in [ISNS]. Note that iSNS security requirements match those for iFCP described in Section 10.3.
発見と経営指導にiSNSプロトコルを使用することでiFCPゲートウェイにセキュリティを供給するために、トンネルモードによるIPSec超能力プロトコルをiFCPゲートウェイにサポートしなければなりません。 iSNSセキュリティ実装要件のさらなる議論は[ISNS]で見つけられます。 iSNSセキュリティ要件がセクション10.3で説明されたiFCPのためのそれらに合っていることに注意してください。
10.5. Use of iSNS to Distribute Security Policy
10.5. 安全保障政策を分配するiSNSの使用
Once communication between iFCP gateways and the iSNS server has been secured through use of IPSec, the iFCP gateways have the capability to discover the security settings that they need to use (or not use) to protect iFCP traffic. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iFCP gateway. It also provides an efficient means for each iFCP gateway to discover the use or non-use of specific security capabilities by peer gateways.
IPSecの使用でいったんiFCPゲートウェイとiSNSサーバとのコミュニケーションを保証すると、iFCPゲートウェイには、彼らが使用する必要があるセキュリティー設定(または、使用でない)がiFCPトラフィックを保護すると発見する能力があります。 これはデバイスごとの個別的安全保障方針の潜在的スケーリング利点構成をそれぞれのiFCPゲートウェイに供給します。 また、それは、同輩ゲートウェイのそばで特定のセキュリティ能力の使用か非使用を発見するためにそれぞれのiFCPゲートウェイに効率的な手段を供給します。
Further discussion on use of iSNS to distribute security policies is found in [ISNS].
安全保障政策を分配するiSNSの使用のさらなる議論は[ISNS]で見つけられます。
10.6. Minimal Security Policy for an iFCP Gateway
10.6. iFCPゲートウェイへの最小量の安全保障政策
An iFCP implementation may be able to disable security mechanisms for an iFCP Portal administratively through a management interface or through security policy elements set in the iSNS server. As a consequence, IKE or IPsec security associations will not be established for any iFCP sessions that traverse the portal.
iFCP実装はiFCP Portalのために管理インタフェースを通して、または、iSNSサーバで設定された安全保障政策要素を通して行政上セキュリティー対策を無効にすることができるかもしれません。結果は、IKEかIPsecセキュリティ協会が入り口を横断するどんなiFCPセッションのためにも書き立てられないでしょう。
For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used in order to provide minimal assurance that connections have initially been opened with the intended counterpart. The minimal iFCP security policy only states that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS].
ほとんどのIPネットワークに、ネットワークとすべての物理的なセキュリティ、管理安全保護、および正しい構成がノードを添付した(テスト研究室の肉体的に孤立しているネットワークは例外であるかもしれない)と仮定するのは不適当です。 したがって、認証SHOULD、接続が初めは意図している対応者と共に開かれたという最小量の保証を提供するには、使用されてください。 最小量のiFCP安全保障政策は、iFCPゲートウェイSHOULDが[ISNS]で説明されるようにiSNSサーバを認証すると述べるだけです。
Monia, et al. Standards Track [Page 99] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[99ページ]RFC4172インターネット繊維チャンネル
11. Quality of Service Considerations
11. サービスの質問題
11.1. Minimal Requirements
11.1. 最小量の要件
Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway, even across one or more intervening best-effort IP regions. The timings with which such gateway-to gateway communication is performed, however, will greatly depend upon BER, packet losses, latency, and jitter experienced throughout the best- effort IP regions. The higher these parameters, the higher the gap measured between iFCP observed behaviors and baseline iFCP behaviors (i.e., as produced by two iFCP gateways directly connected to one another).
従っているiFCPプロトコル実装SHALLは1つ以上の介入しているベストエフォート型IP領域の向こう側にさえ正しくゲートウェイからゲートウェイを伝えます。 タイミング、どのそのようなもの、ゲートウェイ、-、ゲートウェイコミュニケーションは実行されて、しかしながら、最も良い取り組みIP領域中で経験されたBER、パケット損失、潜在、およびジターに大いによるだろうか。 より高いこれらのパラメタであり、測定されたギャップが高ければ高いほど、iFCPは振舞いと基線iFCPの振舞いを観測しました(すなわち、直接お互いに接続された2iFCP門によって生産されるように)。
11.2. High Assurance
11.2. 高い保証
It is expected that many iFCP deployments will benefit from a high degree of assurance regarding the behavior of intervening IP regions, with resulting high assurance on the overall end-to-end path, as directly experienced by fibre channel applications. Such assurance on the IP behaviors stems from the intervening IP regions supporting standard Quality-of-Service (QoS) techniques that are fully complementary to iFCP, such as:
多くのiFCP展開が介入しているIP領域の振舞いに関して高度合いを保証の利益を得ると予想されます、結果として起こる高い保証が終わりから端への総合的な経路にある状態で、繊維チャンネルアプリケーションで直接経験されるように。 IPの振舞いのそのような保証は標準のサービスのQuality(QoS)がiFCPを完全に補足するテクニックであるとサポートする以下などの介入しているIP領域によります。
a) congestion avoidance by over-provisioning of the network,
a) ネットワークの食糧を供給し過ぎるのによる輻輳回避
b) integrated Services [RFC1633] QoS,
b)はServices[RFC1633]QoSを統合しました。
c) differentiated Services [RFC2475] QoS, and
そしてc)がServices[RFC2475]QoSを差別化した。
d) Multi-Protocol Label Switching [RFC3031].
d) マルチプロトコルラベルスイッチング[RFC3031]。
One may load an MPLS forwarding equivalence class (FEC) with QoS class significance, in addition to other considerations such as protection and diversity for the given path. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS shim header.
QoSクラス意味で保護や多様性などの他の問題に加えてMPLS推進同値類(FEC)を与えられた経路に積み込むかもしれません。 Differentiated ServicesとMPLSの補完性と互換性は[MPSLDS]で調査されます。そこでは、PHBビットがMPLS詰め物のヘッダーのEXPビットにコピーされます。
In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions that implement some of the QoS solutions mentioned above. A QoS-capable IP region supports the negotiation and establishment of a service contract specifying the forwarding service through the region. Such contract and negotiation rules are outside the scope of this document. In the case of IP regions with DiffServ QoS, the reader should refer to Service Level Specifications (SLS) and Traffic Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other aspects of a
最も一般的な定義では、2iFCP門は前記のようにQoSソリューションのいくつかを実現する1つ以上の独自に管理されたIP領域によって切り離されます。 QoSできるIP領域は領域を通る推進サービスを指定する役務契約の交渉と設立をサポートします。 このドキュメントの範囲の外にそのような契約と交渉規則があります。 DiffServ QoSがあるIP領域の場合では、読者はService Level Specifications(SLS)とTraffic Conditioning Specifications(TCS)を参照するべきです([DIFTERM]で定義されるように)。 aの他の局面
Monia, et al. Standards Track [Page 100] RFC 4172 Internet Fibre Channel Networking September 2005
Monia、他 2005年9月をネットワークでつないでいる標準化過程[100ページ]RFC4172インターネット繊維チャンネル
service contract are expected to be non-technical and thus are outside of the IETF scope.
役務契約は、非技術系であると予想されて、その結果、IETF範囲の外にあります。
Because fibre channel Class 2 and Class 3 do not currently support fractional bandwidth guarantees, and because iFCP is committed to supporting fibre channel semantics, it is impossible for an iFCP gateway to infer bandwidth requirements autonomously from streaming fibre channel traffic. Rather, the requirements on bandwidth or other network parameters need to be administratively set into an iFCP gateway, or into the entity that will actually negotiate the forwarding service on the gateway's behalf. Depending on the QoS techniques available, the stipulation of a forwarding service may require interaction with network ancillary functions, such as admission control and bandwidth brokers (via RSVP or other signaling protocols that an IP region may accept).
繊維チャンネルClass2とClass3が、現在断片的な帯域幅が保証であるとサポートしないで、iFCPが繊維チャンネル意味論をサポートするよう心がけるので、iFCPゲートウェイがストリーミングの繊維チャンネルトラフィックから帯域幅要件を自主的に推論するのは、不可能です。 むしろ、帯域幅か他の回路パラメータに関する要件は、行政上iFCPゲートウェイの中、または、実際にゲートウェイの利益における推進サービスを交渉する実体の中に設定される必要があります。 利用可能なQoSのテクニックによって、推進サービスの約款は入場などの補助的機能が制御して、帯域幅が仲介する(何らかのIP領域が受け入れるかもしれないとプロトコルに合図するRSVPを通して)ネットワークとの相互作用を必要とするかもしれません。
The administrator of a iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of an iFCP gateway's TCP sessions used by an iFCP gateway. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP- unaware network equipment as well.
The administrator of a iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of an iFCP gateway's TCP sessions used by an iFCP gateway. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP- unaware network equipment as well.
For rendering the best emulation of fibre channel possible over IP, it is anticipated that typical forwarding services will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency and low jitter. For example, an IP region using DiffServ QoS may support SLSes of this nature by applying EF DSCPs to the iFCP traffic.
For rendering the best emulation of fibre channel possible over IP, it is anticipated that typical forwarding services will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency and low jitter. For example, an IP region using DiffServ QoS may support SLSes of this nature by applying EF DSCPs to the iFCP traffic.
12. IANA Considerations
12. IANA Considerations
The IANA-assigned port for iFCP traffic is port number 3420.
The IANA-assigned port for iFCP traffic is port number 3420.
An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed.
An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed.
13. Normative References
13. Normative References
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
Monia, et al. Standards Track [Page 101] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 101] RFC 4172 Internet Fibre Channel Networking September 2005
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M.,
Monia, C., and M. Merhar, "Fibre Channel (FC) Frame
Encapsulation", RFC 3643, December 2003.
[ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C., and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling
(FC-FS), Rev 1.70, INCITS Project 1331D, February 2002
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling (FC-FS), Rev 1.70, INCITS Project 1331D, February 2002
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
GS3)", revision 7.01, INCITS Project 1356-D, November 2000
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- GS3)", revision 7.01, INCITS Project 1356-D, November 2000
[FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC-
SW2)", revision 5.2, INCITS Project 1305-D, May 2001
[FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- SW2)", revision 5.2, INCITS Project 1305-D, May 2001
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second
Version", revision 8, INCITS Project 1144D, September 2002
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second Version", revision 8, INCITS Project 1144D, September 2002
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and
J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171,
September 2005.
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, N.
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, N.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
Monia, et al. Standards Track [Page 102] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 102] RFC 4172 Internet Fibre Channel Networking September 2005
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols Over IP", RFC
3723, April 2004.
[SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols Over IP", RFC 3723, April 2004.
14. Informative References
14. Informative References
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)",
Draft, 2001, Available from
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", Draft, 2001, Available from http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[DIFTERM] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[DIFTERM] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL-
2)", revision 7.0, NCITS Project 1133D, April 1999
[FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 2)", revision 7.0, NCITS Project 1133D, April 1999
[FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC-
FLA)", revision 2.7, NCITS Project 1235-D, August 1997
[FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- FLA)", revision 2.7, NCITS Project 1235-D, August 1997
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface
Architecture Mapping Protocol (FC-VI)", NCITS Project
1332-D, July 2000.
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000.
[KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated
Loop", Robert W. Kembel, Northwest Learning Associates,
2000, ISBN 0-931836-84-0
[KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0
[KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction",
Northwest Learning Associates Inc., 2000, ISBN
0-931836-84-0
[KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0
[MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
Monia, et al. Standards Track [Page 103] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 103] RFC 4172 Internet Fibre Channel Networking September 2005
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June
1994.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated Service",
RFC 2475, December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
Monia, et al. Standards Track [Page 104] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 104] RFC 4172 Internet Fibre Channel Networking September 2005
Appendix A. iFCP Support for Fibre Channel Link Services
Appendix A. iFCP Support for Fibre Channel Link Services
For reference purposes, this appendix enumerates all the fibre channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in Section 7.
For reference purposes, this appendix enumerates all the fibre channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in Section 7.
In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic identifying the protocol.
In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic identifying the protocol.
A.1. Basic Link Services
A.1. Basic Link Services
The basic link services are shown in the following table:
The basic link services are shown in the following table:
Basic Link Services
Basic Link Services
Name Description iFCP Policy
---- ----------- ----------
Name Description iFCP Policy ---- ----------- ----------
ABTS Abort Sequence Transparent
BA_ACC Basic Accept Transparent
BA_RJT Basic Reject Transparent
NOP No Operation Transparent
PRMT Preempted Rejected
(Applies to
Class 1 only)
RMC Remove Connection Rejected
(Applies to
Class 1 only)
ABTS Abort Sequence Transparent BA_ACC Basic Accept Transparent BA_RJT Basic Reject Transparent NOP No Operation Transparent PRMT Preempted Rejected (Applies to Class 1 only) RMC Remove Connection Rejected (Applies to Class 1 only)
A.2. Pass-Through Link Services
A.2. Pass-Through Link Services
As specified in Section 7, the link service requests of Table 10 and the associated ACC response frames MUST be passed to the receiving N_PORT without altering the payload.
As specified in Section 7, the link service requests of Table 10 and the associated ACC response frames MUST be passed to the receiving N_PORT without altering the payload.
Name Description
---- -----------
Name Description ---- -----------
ADVC Advise Credit
CSR Clock Synchronization Request
CSU Clock Synchronization Update
ECHO Echo
ESTC Estimate Credit
ESTS Establish Streaming
FACT Fabric Activate Alias_ID
FAN Fabric Address Notification
ADVC Advise Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO Echo ESTC Estimate Credit ESTS Establish Streaming FACT Fabric Activate Alias_ID FAN Fabric Address Notification
Monia, et al. Standards Track [Page 105] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 105] RFC 4172 Internet Fibre Channel Networking September 2005
FCP_RJT FCP FC-4 Link Service Reject
FCP SRR FCP Sequence Retransmission
Request
FDACT Fabric Deactivate Alias_ID
FDISC Discover F_Port Service
Parameters
FLOGI F_Port Login
GAID Get Alias_ID
LCLM Login Control List Management
LINIT Loop Initialize
LIRR Link Incident Record
Registration
LPC Loop Port Control
LS_RJT Link Service Reject
LSTS Loop Status
NACT N_Port Activate Alias_ID
NDACT N_Port Deactivate Alias_ID
PDISC Discover N_Port Service
Parameters
PRLI Process Login
PRLO Process Logout
QoSR Quality of Service Request
RCS Read Connection Status
RLIR Registered Link Incident
Report
RNC Report Node Capability
RNFT Report Node FC-4 Types
RNID Request Node Identification
Data
RPL Read Port List
RPS Read Port Status Block
RPSC Report Port Speed
Capabilities
RSCN Registered State Change
Notification
RTV Read Timeout Value
RVCS Read Virtual Circuit Status
SBRP Set Bit-Error Reporting
Parameters
SCN State Change Notification
SCR State Change Registration
TEST Test
TPLS Test Process Login State
FCP_RJT FCP FC-4 Link Service Reject FCP SRR FCP Sequence Retransmission Request FDACT Fabric Deactivate Alias_ID FDISC Discover F_Port Service Parameters FLOGI F_Port Login GAID Get Alias_ID LCLM Login Control List Management LINIT Loop Initialize LIRR Link Incident Record Registration LPC Loop Port Control LS_RJT Link Service Reject LSTS Loop Status NACT N_Port Activate Alias_ID NDACT N_Port Deactivate Alias_ID PDISC Discover N_Port Service Parameters PRLI Process Login PRLO Process Logout QoSR Quality of Service Request RCS Read Connection Status RLIR Registered Link Incident Report RNC Report Node Capability RNFT Report Node FC-4 Types RNID Request Node Identification Data RPL Read Port List RPS Read Port Status Block RPSC Report Port Speed Capabilities RSCN Registered State Change Notification RTV Read Timeout Value RVCS Read Virtual Circuit Status SBRP Set Bit-Error Reporting Parameters SCN State Change Notification SCR State Change Registration TEST Test TPLS Test Process Login State
Table 10. Pass-Through Link Services
Table 10. Pass-Through Link Services
Monia, et al. Standards Track [Page 106] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 106] RFC 4172 Internet Fibre Channel Networking September 2005
A.3. Special Link Services
A.3. Special Link Services
The extended and FC-4 link services of Table 11 are processed by an iFCP implementation as described in the sections referenced in the table.
The extended and FC-4 link services of Table 11 are processed by an iFCP implementation as described in the sections referenced in the table.
Name Description Section
---- ----------- -------
Name Description Section ---- ----------- -------
ABTX Abort Exchange 7.3.1.1
ADISC Discover Address 7.3.1.2
ADISC Discover Address Accept 7.3.1.3
ACC
FARP- Fibre Channel Address 7.3.1.4
REPLY Resolution Protocol
Reply
FARP- Fibre Channel Address 7.3.1.5
REQ Resolution Protocol
Request
LOGO N_PORT Logout 7.3.1.6
PLOGI Port Login 7.3.1.7
REC Read Exchange Concise 7.3.1.8
REC ACC Read Exchange Concise 7.3.1.9
Accept
FCP REC FCP Read Exchange 7.3.2.1.1
Concise (see [FCP-2])
FCP REC FCP Read Exchange 7.3.2.1.2
ACC Concise Accept (see
[FCP-2])
RES Read Exchange Status 7.3.1.10
Block
RES ACC Read Exchange Status 7.3.1.11
Block Accept
RLS Read Link Error Status 7.3.1.12
Block
RRQ Reinstate Recovery 7.3.1.14
Qualifier
RSI Request Sequence 7.3.1.15
Initiative
RSS Read Sequence Status 7.3.1.13
Block
SRL Scan Remote Loop 7.3.1.16
TPRLO Third Party Process 7.3.1.17
Logout
TPRLO Third Party Process 7.3.1.18
ACC Logout Accept
ABTX Abort Exchange 7.3.1.1 ADISC Discover Address 7.3.1.2 ADISC Discover Address Accept 7.3.1.3 ACC FARP- Fibre Channel Address 7.3.1.4 REPLY Resolution Protocol Reply FARP- Fibre Channel Address 7.3.1.5 REQ Resolution Protocol Request LOGO N_PORT Logout 7.3.1.6 PLOGI Port Login 7.3.1.7 REC Read Exchange Concise 7.3.1.8 REC ACC Read Exchange Concise 7.3.1.9 Accept FCP REC FCP Read Exchange 7.3.2.1.1 Concise (see [FCP-2]) FCP REC FCP Read Exchange 7.3.2.1.2 ACC Concise Accept (see [FCP-2]) RES Read Exchange Status 7.3.1.10 Block RES ACC Read Exchange Status 7.3.1.11 Block Accept RLS Read Link Error Status 7.3.1.12 Block RRQ Reinstate Recovery 7.3.1.14 Qualifier RSI Request Sequence 7.3.1.15 Initiative RSS Read Sequence Status 7.3.1.13 Block SRL Scan Remote Loop 7.3.1.16 TPRLO Third Party Process 7.3.1.17 Logout TPRLO Third Party Process 7.3.1.18 ACC Logout Accept
Table 11. Special Link Services
Table 11. Special Link Services
Monia, et al. Standards Track [Page 107] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 107] RFC 4172 Internet Fibre Channel Networking September 2005
Appendix B. Supporting the Fibre Channel Loop Topology
Appendix B. Supporting the Fibre Channel Loop Topology
A loop topology may be optionally supported by a gateway implementation in one of the following ways:
A loop topology may be optionally supported by a gateway implementation in one of the following ways:
a) By implementing the FL_PORT public loop interface specified in
[FC-FLA].
a) By implementing the FL_PORT public loop interface specified in [FC-FLA].
b) By emulating the private loop environment specified in [FC-AL2].
b) By emulating the private loop environment specified in [FC-AL2].
Private loop emulation allows the attachment of fibre channel devices that do not support fabrics or public loops. The gateway presents such devices to the fabric as though they were fabric-attached. Conversely, the gateway presents devices on the fabric, whether they are locally or remotely attached, as though they were connected to the private loop.
Private loop emulation allows the attachment of fibre channel devices that do not support fabrics or public loops. The gateway presents such devices to the fabric as though they were fabric-attached. Conversely, the gateway presents devices on the fabric, whether they are locally or remotely attached, as though they were connected to the private loop.
Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session.
Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session.
B.1. Remote Control of a Public Loop
B.1. Remote Control of a Public Loop
A gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier through which the public loop may be remotely controlled.
A gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier through which the public loop may be remotely controlled.
The LFA and FL_PORT address identifier both represent an N_PORT that services remote loop management requests contained in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias so that the corresponding alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero.
The LFA and FL_PORT address identifier both represent an N_PORT that services remote loop management requests contained in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias so that the corresponding alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero.
Monia, et al. Standards Track [Page 108] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 108] RFC 4172 Internet Fibre Channel Networking September 2005
Acknowledgements
Acknowledgements
The authors are indebted to those who contributed material and who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel).
The authors are indebted to those who contributed material and who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel).
Monia, et al. Standards Track [Page 109] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 109] RFC 4172 Internet Fibre Channel Networking September 2005
Author's Addresses
Author's Addresses
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
Charles Monia 7553 Morevern Circle San Jose, CA 95135
Charles Monia 7553 Morevern Circle San Jose, CA 95135
EMail: charles_monia@yahoo.com
EMail: charles_monia@yahoo.com
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Phone: 978-288-7708 EMail: travos@nortel.com
Phone: 978-288-7708 EMail: travos@nortel.com
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
Phone: +44 (0)117 930 9600 EMail: mark_edwards@adaptec.com
Phone: +44 (0)117 930 9600 EMail: mark_edwards@adaptec.com
Monia, et al. Standards Track [Page 110] RFC 4172 Internet Fibre Channel Networking September 2005
Monia, et al. Standards Track [Page 110] RFC 4172 Internet Fibre Channel Networking September 2005
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Monia, et al. Standards Track [Page 111]
Monia, et al. Standards Track [Page 111]
一覧
スポンサーリンク
