RFC3821 日本語訳
3821 Fibre Channel Over TCP/IP (FCIP). M. Rajagopal, E. Rodriguez, R.Weber. July 2004. (Format: TXT=165907 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Rajagopal
Request for Comments: 3821 E. Rodriguez
Category: Standards Track R. Weber
July 2004
Network Working Group M. Rajagopal Request for Comments: 3821 E. Rodriguez Category: Standards Track R. Weber July 2004
Fibre Channel Over TCP/IP (FCIP)
Fibre Channel Over TCP/IP (FCIP)
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
Abstract
Abstract
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
Table Of Contents
Table Of Contents
1. Purpose, Motivation, and Objectives. . . . . . . . . . . . . . 3
2. Relationship to Fibre Channel Standards. . . . . . . . . . . . 4
2.1. Relevant Fibre Channel Standards . . . . . . . . . . . . 4
2.2. This Specification and Fibre Channel Standards . . . . . 5
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 7
5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. FCIP Protocol Model. . . . . . . . . . . . . . . . . . . 9
5.2. FCIP Link. . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. FC Entity. . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. FCIP Entity. . . . . . . . . . . . . . . . . . . . . . . 12
5.5. FCIP Link Endpoint (FCIP_LEP). . . . . . . . . . . . . . 13
5.6. FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . 14
5.6.1. FCIP Encapsulation of FC Frames. . . . . . . . . 16
5.6.2. FCIP Data Engine Error Detection and Recovery. . 19
6. Checking FC Frame Transit Times in the IP Network. . . . . . . 22
1. Purpose, Motivation, and Objectives. . . . . . . . . . . . . . 3 2. Relationship to Fibre Channel Standards. . . . . . . . . . . . 4 2.1. Relevant Fibre Channel Standards . . . . . . . . . . . . 4 2.2. This Specification and Fibre Channel Standards . . . . . 5 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 7 5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. FCIP Protocol Model. . . . . . . . . . . . . . . . . . . 9 5.2. FCIP Link. . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. FC Entity. . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. FCIP Entity. . . . . . . . . . . . . . . . . . . . . . . 12 5.5. FCIP Link Endpoint (FCIP_LEP). . . . . . . . . . . . . . 13 5.6. FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . 14 5.6.1. FCIP Encapsulation of FC Frames. . . . . . . . . 16 5.6.2. FCIP Data Engine Error Detection and Recovery. . 19 6. Checking FC Frame Transit Times in the IP Network. . . . . . . 22
Rajagopal, et al. Standards Track [Page 1] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 1] RFC 3821 FCIP July 2004
7. The FCIP Special Frame (FSF) . . . . . . . . . . . . . . . . . 23
7.1. FCIP Special Frame Format. . . . . . . . . . . . . . . . 23
7.2. Overview of FSF Usage in Connection Establishment. . . . 26
8. TCP Connection Management. . . . . . . . . . . . . . . . . . . 28
8.1. TCP Connection Establishment . . . . . . . . . . . . . . 28
8.1.1. Connection Establishment Model . . . . . . . . . 28
8.1.2. Creating New TCP Connections . . . . . . . . . . 29
8.1.3. Processing Incoming TCP Connect Requests . . . . 32
8.1.4. Simultaneous Connection Establishment. . . . . . 36
8.2. Closing TCP Connections. . . . . . . . . . . . . . . . . 36
8.3. TCP Connection Parameters. . . . . . . . . . . . . . . . 36
8.3.1. TCP Selective Acknowledgement Option . . . . . . 36
8.3.2. TCP Window Scale Option. . . . . . . . . . . . . 36
8.3.3. Protection Against Sequence Number Wrap. . . . . 37
8.3.4. TCP_NODELAY Option . . . . . . . . . . . . . . . 37
8.4. TCP Connection Considerations. . . . . . . . . . . . . . 37
8.5. Flow Control Mapping between TCP and FC. . . . . . . . . 37
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Threat Models. . . . . . . . . . . . . . . . . . . . . . 38
9.2. FC Fabric and IP Network Deployment Models . . . . . . . 40
9.3. FCIP Security Components . . . . . . . . . . . . . . . . 40
9.3.1. IPsec ESP Authentication and Confidentiality . . 40
9.3.2. Key Management . . . . . . . . . . . . . . . . . 41
9.3.3. ESP Replay Protection and Rekeying Issues. . . . 43
9.4. Secure FCIP Link Operation . . . . . . . . . . . . . . . 44
9.4.1. FCIP Link Initialization Steps . . . . . . . . . 44
9.4.2. TCP Connection Security Associations (SAs) . . . 44
9.4.3. Handling Data Integrity and Confidentiality
Violations . . . . . . . . . . . . . . . . . . . 45
10. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Performance Considerations . . . . . . . . . . . . . . . 45
10.2. IP Quality of Service (QoS) Support. . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 49
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix A Fibre Channel Bit and Byte Numbering Guidance. . . . . 51
B IANA Considerations. . . . . . . . . . . . . . . . . . 51
C FCIP Usage of Addresses and Identifiers. . . . . . . . 52
D Example of synchronization Recovery Algorithm. . . . . 53
E Relationship between FCIP and IP over FC (IPFC). . . . 58
F FC Frame Format. . . . . . . . . . . . . . . . . . . . 59
G FC Encapsulation Format. . . . . . . . . . . . . . . . 61
H FCIP Requirements on an FC Entity. . . . . . . . . . . 63
Editors and Contributors Acknowledgements. . . . . . . . . . . . . 69
Editors and Contributors Addresses . . . . . . . . . . . . . . . . 70
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
7. The FCIP Special Frame (FSF) . . . . . . . . . . . . . . . . . 23 7.1. FCIP Special Frame Format. . . . . . . . . . . . . . . . 23 7.2. Overview of FSF Usage in Connection Establishment. . . . 26 8. TCP Connection Management. . . . . . . . . . . . . . . . . . . 28 8.1. TCP Connection Establishment . . . . . . . . . . . . . . 28 8.1.1. Connection Establishment Model . . . . . . . . . 28 8.1.2. Creating New TCP Connections . . . . . . . . . . 29 8.1.3. Processing Incoming TCP Connect Requests . . . . 32 8.1.4. Simultaneous Connection Establishment. . . . . . 36 8.2. Closing TCP Connections. . . . . . . . . . . . . . . . . 36 8.3. TCP Connection Parameters. . . . . . . . . . . . . . . . 36 8.3.1. TCP Selective Acknowledgement Option . . . . . . 36 8.3.2. TCP Window Scale Option. . . . . . . . . . . . . 36 8.3.3. Protection Against Sequence Number Wrap. . . . . 37 8.3.4. TCP_NODELAY Option . . . . . . . . . . . . . . . 37 8.4. TCP Connection Considerations. . . . . . . . . . . . . . 37 8.5. Flow Control Mapping between TCP and FC. . . . . . . . . 37 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Threat Models. . . . . . . . . . . . . . . . . . . . . . 38 9.2. FC Fabric and IP Network Deployment Models . . . . . . . 40 9.3. FCIP Security Components . . . . . . . . . . . . . . . . 40 9.3.1. IPsec ESP Authentication and Confidentiality . . 40 9.3.2. Key Management . . . . . . . . . . . . . . . . . 41 9.3.3. ESP Replay Protection and Rekeying Issues. . . . 43 9.4. Secure FCIP Link Operation . . . . . . . . . . . . . . . 44 9.4.1. FCIP Link Initialization Steps . . . . . . . . . 44 9.4.2. TCP Connection Security Associations (SAs) . . . 44 9.4.3. Handling Data Integrity and Confidentiality Violations . . . . . . . . . . . . . . . . . . . 45 10. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.1. Performance Considerations . . . . . . . . . . . . . . . 45 10.2. IP Quality of Service (QoS) Support. . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.1. Normative References . . . . . . . . . . . . . . . . . . 47 11.2. Informative References . . . . . . . . . . . . . . . . . 49 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix A Fibre Channel Bit and Byte Numbering Guidance. . . . . 51 B IANA Considerations. . . . . . . . . . . . . . . . . . 51 C FCIP Usage of Addresses and Identifiers. . . . . . . . 52 D Example of synchronization Recovery Algorithm. . . . . 53 E Relationship between FCIP and IP over FC (IPFC). . . . 58 F FC Frame Format. . . . . . . . . . . . . . . . . . . . 59 G FC Encapsulation Format. . . . . . . . . . . . . . . . 61 H FCIP Requirements on an FC Entity. . . . . . . . . . . 63 Editors and Contributors Acknowledgements. . . . . . . . . . . . . 69 Editors and Contributors Addresses . . . . . . . . . . . . . . . . 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
Rajagopal, et al. Standards Track [Page 2] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 2] RFC 3821 FCIP July 2004
1. Purpose, Motivation, and Objectives
1. Purpose, Motivation, and Objectives
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different. See appendix A for guidance.
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different. See appendix A for guidance.
Fibre Channel (FC) is a gigabit or multi-gigabit speed networking technology primarily used to implement Storage Area Networks (SANs). See section 2 for information about how Fibre Channel is standardized and the relationship of this specification to Fibre Channel standards. An overview of Fibre Channel can be found in [34].
Fibre Channel (FC) is a gigabit or multi-gigabit speed networking technology primarily used to implement Storage Area Networks (SANs). See section 2 for information about how Fibre Channel is standardized and the relationship of this specification to Fibre Channel standards. An overview of Fibre Channel can be found in [34].
This specification describes mechanisms that allow the interconnection of islands of Fibre Channel SANs over IP Networks to form a unified SAN in a single Fibre Channel fabric. The motivation behind defining these interconnection mechanisms is a desire to connect physically remote FC sites allowing remote disk access, tape backup, and live mirroring.
This specification describes mechanisms that allow the interconnection of islands of Fibre Channel SANs over IP Networks to form a unified SAN in a single Fibre Channel fabric. The motivation behind defining these interconnection mechanisms is a desire to connect physically remote FC sites allowing remote disk access, tape backup, and live mirroring.
Fibre Channel standards have chosen nominal distances between switch elements that are less than the distances available in an IP Network. Since Fibre Channel and IP Networking technologies are compatible, it is logical to turn to IP Networking for extending the allowable distances between Fibre Channel switch elements.
Fibre Channel standards have chosen nominal distances between switch elements that are less than the distances available in an IP Network. Since Fibre Channel and IP Networking technologies are compatible, it is logical to turn to IP Networking for extending the allowable distances between Fibre Channel switch elements.
The fundamental assumption made in this specification is that the Fibre Channel traffic is carried over the IP Network in such a manner that the Fibre Channel Fabric and all Fibre Channel devices on the Fabric are unaware of the presence of the IP Network. This means that the FC datagrams must be delivered in such time as to comply with existing Fibre Channel specifications. The FC traffic may span LANs, MANs, and WANs, so long as this fundamental assumption is adhered to.
The fundamental assumption made in this specification is that the Fibre Channel traffic is carried over the IP Network in such a manner that the Fibre Channel Fabric and all Fibre Channel devices on the Fabric are unaware of the presence of the IP Network. This means that the FC datagrams must be delivered in such time as to comply with existing Fibre Channel specifications. The FC traffic may span LANs, MANs, and WANs, so long as this fundamental assumption is adhered to.
The objectives of this document are to:
The objectives of this document are to:
1) specify the encapsulation and mapping of Fibre Channel (FC) frames
employing FC Frame Encapsulation [19].
1) specify the encapsulation and mapping of Fibre Channel (FC) frames employing FC Frame Encapsulation [19].
2) apply the mechanism described in 1) to an FC Fabric using an IP
network as an interconnect between two or more islands in an FC
Fabric.
2) apply the mechanism described in 1) to an FC Fabric using an IP network as an interconnect between two or more islands in an FC Fabric.
3) address any FC concerns arising from tunneling FC traffic over an
IP-based network, including security, data integrity (loss),
congestion, and performance. This will be accomplished by
utilizing the existing IETF-specified suite of protocols.
3) address any FC concerns arising from tunneling FC traffic over an IP-based network, including security, data integrity (loss), congestion, and performance. This will be accomplished by utilizing the existing IETF-specified suite of protocols.
Rajagopal, et al. Standards Track [Page 3] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 3] RFC 3821 FCIP July 2004
4) be compatible with the referenced FC standards. While new work
may be undertaken in T11 to optimize and enhance FC Fabrics, this
specification REQUIRES conformance only to the referenced FC
standards.
4) be compatible with the referenced FC standards. While new work may be undertaken in T11 to optimize and enhance FC Fabrics, this specification REQUIRES conformance only to the referenced FC standards.
5) be compatible with all applicable IETF standards so that the IP
Network used to extend an FC Fabric can be used concurrently for
other reasonable purposes.
5) be compatible with all applicable IETF standards so that the IP Network used to extend an FC Fabric can be used concurrently for other reasonable purposes.
The objectives of this document do not include using an IP Network as a replacement for the Fibre Channel Arbitrated Loop interconnect. No definition is provided for encapsulating loop primitive signals for transmission over an IP Network.
The objectives of this document do not include using an IP Network as a replacement for the Fibre Channel Arbitrated Loop interconnect. No definition is provided for encapsulating loop primitive signals for transmission over an IP Network.
Conventions used in this document
Conventions used in this document
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 [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 [1].
2. Relationship to Fibre Channel Standards
2. Relationship to Fibre Channel Standards
2.1. Relevant Fibre Channel Standards
2.1. Relevant Fibre Channel Standards
FC is standardized as a family of American National Standards developed by the T11 technical committee of INCITS (InterNational Committee for Information Technology Standards). T11 has specified a number of documents describing FC protocols, operations, and services. T11 documents of interest to readers of this specification include (but are not limited to):
FC is standardized as a family of American National Standards developed by the T11 technical committee of INCITS (InterNational Committee for Information Technology Standards). T11 has specified a number of documents describing FC protocols, operations, and services. T11 documents of interest to readers of this specification include (but are not limited to):
- FC-BB - Fibre Channel Backbone [2]
- FC-BB-2 - Fibre Channel Backbone -2 [3]
- FC-SW-2 - Fibre Channel Switch Fabric -2 [4]
- FC-FS - Fibre Channel Framing and Signaling [5]
- FC-BB - Fibre Channel Backbone [2] - FC-BB-2 - Fibre Channel Backbone -2 [3] - FC-SW-2 - Fibre Channel Switch Fabric -2 [4] - FC-FS - Fibre Channel Framing and Signaling [5]
FC-BB and FC-BB-2 describe the relationship between an FC Fabric and interconnect technologies not defined by Fibre Channel standards (e.g., ATM and SONET). FC-BB-2 is the Fibre Channel document describing the relationships between FC and TCP/IP, including the FC use of FCIP.
FC-BB and FC-BB-2 describe the relationship between an FC Fabric and interconnect technologies not defined by Fibre Channel standards (e.g., ATM and SONET). FC-BB-2 is the Fibre Channel document describing the relationships between FC and TCP/IP, including the FC use of FCIP.
FC-SW-2 describes the switch components of an FC Fabric and FC-FS describes the FC Frame format and basic control features of Fibre Channel.
FC-SW-2 describes the switch components of an FC Fabric and FC-FS describes the FC Frame format and basic control features of Fibre Channel.
Additional information regarding T11 activities is available on the committee's web site www.t11.org.
Additional information regarding T11 activities is available on the committee's web site www.t11.org.
Rajagopal, et al. Standards Track [Page 4] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 4] RFC 3821 FCIP July 2004
2.2. This Specification and Fibre Channel Standards
2.2. This Specification and Fibre Channel Standards
When considering the challenge of transporting FC Frames over an IP Network, it is logical to divide the standardization effort between TCP/IP requirements and Fibre Channel requirements. This specification covers the TCP/IP requirements for transporting FC Frames; the Fibre Channel documents described in section 2.1 cover the Fibre Channel requirements.
When considering the challenge of transporting FC Frames over an IP Network, it is logical to divide the standardization effort between TCP/IP requirements and Fibre Channel requirements. This specification covers the TCP/IP requirements for transporting FC Frames; the Fibre Channel documents described in section 2.1 cover the Fibre Channel requirements.
This specification addresses only the requirements necessary to properly utilize an IP Network as a conduit for FC Frames. The result is a specification for an FCIP Entity (see section 5.4).
This specification addresses only the requirements necessary to properly utilize an IP Network as a conduit for FC Frames. The result is a specification for an FCIP Entity (see section 5.4).
A product that tunnels an FC Fabric through an IP Network MUST combine the FCIP Entity with an FC Entity (see section 5.3) using an implementation specific interface. The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
A product that tunnels an FC Fabric through an IP Network MUST combine the FCIP Entity with an FC Entity (see section 5.3) using an implementation specific interface. The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
No attempt is being made to define a specific API between an FCIP Entity and an FC Entity. The approach is to specify required functional interactions between an FCIP Entity and an FC Entity (both of which are required to forward FC frames across an IP Network), but allow implementers to choose how these interactions will be realized.
No attempt is being made to define a specific API between an FCIP Entity and an FC Entity. The approach is to specify required functional interactions between an FCIP Entity and an FC Entity (both of which are required to forward FC frames across an IP Network), but allow implementers to choose how these interactions will be realized.
3. Terminology
3. Terminology
Terms used to describe FCIP concepts are defined in this section.
Terms used to describe FCIP concepts are defined in this section.
FC End Node - An FC device that uses the connection services provided
by the FC Fabric.
FC End Node - An FC device that uses the connection services provided by the FC Fabric.
FC Entity - The Fibre Channel specific functional component that
combines with an FCIP Entity to form an interface between an FC
Fabric and an IP Network (see section 5.3).
FC Entity - The Fibre Channel specific functional component that combines with an FCIP Entity to form an interface between an FC Fabric and an IP Network (see section 5.3).
FC Fabric - An entity that interconnects various Nx_Ports (see [5])
attached to it, and is capable of routing FC Frames using only the
destination ID information in an FC Frame header (see appendix F).
FC Fabric - An entity that interconnects various Nx_Ports (see [5]) attached to it, and is capable of routing FC Frames using only the destination ID information in an FC Frame header (see appendix F).
FC Fabric Entity - A Fibre Channel specific element containing one
or more Interconnect_Ports (see FC-SW-2 [4]) and one or more
FC/FCIP Entity pairs. See FC-BB-2 [3] for details about FC Fabric
Entities.
FC Fabric Entity - A Fibre Channel specific element containing one or more Interconnect_Ports (see FC-SW-2 [4]) and one or more FC/FCIP Entity pairs. See FC-BB-2 [3] for details about FC Fabric Entities.
Rajagopal, et al. Standards Track [Page 5] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 5] RFC 3821 FCIP July 2004
FC Frame - The basic unit of Fibre Channel data transfer (see
appendix F).
FC Frame - The basic unit of Fibre Channel data transfer (see appendix F).
FC Frame Receiver Portal - The access point through which an FC
Frame and time stamp enter an FCIP Data Engine from the FC Entity.
FC Frame Receiver Portal - The access point through which an FC Frame and time stamp enter an FCIP Data Engine from the FC Entity.
FC Frame Transmitter Portal - The access point through which a
reconstituted FC Frame and time stamp leave an FCIP Data Engine to
the FC Entity.
FC Frame Transmitter Portal - The access point through which a reconstituted FC Frame and time stamp leave an FCIP Data Engine to the FC Entity.
FC/FCIP Entity pair - The combination of one FC Entity and one FCIP
entity.
FC/FCIP Entity pair - The combination of one FC Entity and one FCIP entity.
FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that
handles FC Frame encapsulation, de-encapsulation, and transmission
FCIP Frames through a single TCP Connection (see section 5.6).
FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that handles FC Frame encapsulation, de-encapsulation, and transmission FCIP Frames through a single TCP Connection (see section 5.6).
FCIP Entity - The entity responsible for the FCIP protocol exchanges
on the IP Network and encompasses FCIP_LEP(s) and FCIP Control and
Services module (see section 5.4).
FCIP Entity - The entity responsible for the FCIP protocol exchanges on the IP Network and encompasses FCIP_LEP(s) and FCIP Control and Services module (see section 5.4).
FCIP Frame - An FC Frame plus the FC Frame Encapsulation [19]
header, encoded SOF and encoded EOF that contains the FC Frame
(see section 5.6.1).
FCIP Frame - An FC Frame plus the FC Frame Encapsulation [19] header, encoded SOF and encoded EOF that contains the FC Frame (see section 5.6.1).
FCIP Link - One or more TCP Connections that connect one FCIP_LEP to
another (see section 5.2).
FCIP Link - One or more TCP Connections that connect one FCIP_LEP to another (see section 5.2).
FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity
that handles a single FCIP Link and contains one or more FCIP_DEs
(see section 5.5).
FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that handles a single FCIP Link and contains one or more FCIP_DEs (see section 5.5).
Encapsulated Frame Receiver Portal - The TCP access point through
which an FCIP Frame is received from the IP Network by an FCIP
Data Engine.
Encapsulated Frame Receiver Portal - The TCP access point through which an FCIP Frame is received from the IP Network by an FCIP Data Engine.
Encapsulated Frame Transmitter Portal - The TCP access point through
which an FCIP Frame is transmitted to the IP Network by an FCIP
Data Engine.
Encapsulated Frame Transmitter Portal - The TCP access point through which an FCIP Frame is transmitted to the IP Network by an FCIP Data Engine.
FCIP Special Frame (FSF) - A specially formatted FC Frame containing
information used by the FCIP protocol (see section 7).
FCIP Special Frame (FSF) - A specially formatted FC Frame containing information used by the FCIP protocol (see section 7).
Rajagopal, et al. Standards Track [Page 6] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 6] RFC 3821 FCIP July 2004
4. Protocol Summary
4. Protocol Summary
The FCIP protocol is summarized as follows:
The FCIP protocol is summarized as follows:
1) The primary function of an FCIP Entity is forwarding FC Frames,
employing FC Frame Encapsulation described in [19].
1) The primary function of an FCIP Entity is forwarding FC Frames, employing FC Frame Encapsulation described in [19].
2) Viewed from the IP Network perspective, FCIP Entities are peers
and communicate using TCP/IP. Each FCIP Entity contains one or
more TCP endpoints in the IP-based network.
2) Viewed from the IP Network perspective, FCIP Entities are peers and communicate using TCP/IP. Each FCIP Entity contains one or more TCP endpoints in the IP-based network.
3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, in
combination with their associated FC Entities, forward FC Frames
between FC Fabric elements. The FC End Nodes are unaware of the
existence of the FCIP Link.
3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, in combination with their associated FC Entities, forward FC Frames between FC Fabric elements. The FC End Nodes are unaware of the existence of the FCIP Link.
4) FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames
are not transmitted across an FCIP Link because they cannot be
encoded using FC Frame Encapsulation [19].
4) FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames are not transmitted across an FCIP Link because they cannot be encoded using FC Frame Encapsulation [19].
5) The path (route) taken by an encapsulated FC Frame follows the
normal routing procedures of the IP Network.
5) The path (route) taken by an encapsulated FC Frame follows the normal routing procedures of the IP Network.
6) An FCIP Entity MAY contain multiple FCIP Link Endpoints, but each
FCIP Link Endpoint (FCIP_LEP) communicates with exactly one other
FCIP_LEP.
6) An FCIP Entity MAY contain multiple FCIP Link Endpoints, but each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one other FCIP_LEP.
7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use,
selection of which FCIP_DE to use for encapsulating and
transmitting a given FC Frame is covered in FC-BB-2 [3]. FCIP
Entities do not actively participate in FC Frame routing.
7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, selection of which FCIP_DE to use for encapsulating and transmitting a given FC Frame is covered in FC-BB-2 [3]. FCIP Entities do not actively participate in FC Frame routing.
8) The FCIP Control and Services module MAY use TCP/IP quality of
service features (see section 10.2).
8) The FCIP Control and Services module MAY use TCP/IP quality of service features (see section 10.2).
9) It is necessary to statically or dynamically configure each FCIP
entity with the IP addresses and TCP port numbers corresponding to
FCIP Entities with which it is expected to initiate communication.
If dynamic discovery of participating FCIP Entities is supported,
the function SHALL be performed using the Service Location
Protocol (SLPv2) [17]. It is outside the scope of this
specification to describe any static configuration method for
participating FCIP Entity discovery. Refer to section 8.1.2.2 for
a detailed description of dynamic discovery of participating FCIP
Entities using SLPv2.
9) It is necessary to statically or dynamically configure each FCIP entity with the IP addresses and TCP port numbers corresponding to FCIP Entities with which it is expected to initiate communication. If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17]. It is outside the scope of this specification to describe any static configuration method for participating FCIP Entity discovery. Refer to section 8.1.2.2 for a detailed description of dynamic discovery of participating FCIP Entities using SLPv2.
Rajagopal, et al. Standards Track [Page 7] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 7] RFC 3821 FCIP July 2004
10) Before creating a TCP Connection to a peer FCIP Entity, the FCIP
Entity attempting to create the TCP connection SHALL statically or
dynamically determine the IP address, TCP port, expected FC Fabric
Entity World Wide Name, TCP Connection Parameters, and Quality of
Service Information.
10) Before creating a TCP Connection to a peer FCIP Entity, the FCIP Entity attempting to create the TCP connection SHALL statically or dynamically determine the IP address, TCP port, expected FC Fabric Entity World Wide Name, TCP Connection Parameters, and Quality of Service Information.
11) FCIP Entities do not actively participate in the discovery of FC
source and destination identifiers. Discovery of FC addresses
(accessible via the FCIP Entity) is provided by techniques and
protocols within the FC architecture as described in FC-FS [5] and
FC-SW-2 [4].
11) FCIP Entities do not actively participate in the discovery of FC source and destination identifiers. Discovery of FC addresses (accessible via the FCIP Entity) is provided by techniques and protocols within the FC architecture as described in FC-FS [5] and FC-SW-2 [4].
12) To support IP Network security (see section 9), FCIP Entities
MUST:
1) implement cryptographically protected authentication and
cryptographic data integrity keyed to the authentication
process, and
2) implement data confidentiality security features.
12) To support IP Network security (see section 9), FCIP Entities MUST: 1) implement cryptographically protected authentication and cryptographic data integrity keyed to the authentication process, and 2) implement data confidentiality security features.
13) On an individual TCP Connection, this specification relies on
TCP/IP to deliver a byte stream in the same order that it was
sent.
13) On an individual TCP Connection, this specification relies on TCP/IP to deliver a byte stream in the same order that it was sent.
14) This specification assumes the presence of and requires the use of
TCP and FC data loss and corruption mechanisms. The error
detection and recovery features described in this specification
complement and support these existing mechanisms.
14) This specification assumes the presence of and requires the use of TCP and FC data loss and corruption mechanisms. The error detection and recovery features described in this specification complement and support these existing mechanisms.
Rajagopal, et al. Standards Track [Page 8] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 8] RFC 3821 FCIP July 2004
5. The FCIP Model
5. The FCIP Model
5.1. FCIP Protocol Model
5.1. FCIP Protocol Model
The relationship between FCIP and other protocols is illustrated in figure 1.
The relationship between FCIP and other protocols is illustrated in figure 1.
+------------------------+ FCIP Link +------------------------+
| FCIP |===========| FCIP |
+--------+------+--------+ +--------+------+--------+
| FC-2 | | TCP | | TCP | | FC-2 |
+--------+ +--------+ +--------+ +--------+
| FC-1 | | IP | | IP | | FC-1 |
+--------+ +--------+ +--------+ +--------+
| FC-0 | | LINK | | LINK | | FC-0 |
+--------+ +--------+ +--------+ +--------+
| | PHY | | PHY | |
| +--------+ +--------+ |
| | | |
| | IP Network | |
V +--------------------+ V
to Fibre to Fibre
Channel Channel
Fabric Fabric
+------------------------+ FCIP Link +------------------------+ | FCIP |===========| FCIP | +--------+------+--------+ +--------+------+--------+ | FC-2 | | TCP | | TCP | | FC-2 | +--------+ +--------+ +--------+ +--------+ | FC-1 | | IP | | IP | | FC-1 | +--------+ +--------+ +--------+ +--------+ | FC-0 | | LINK | | LINK | | FC-0 | +--------+ +--------+ +--------+ +--------+ | | PHY | | PHY | | | +--------+ +--------+ | | | | | | | IP Network | | V +--------------------+ V to Fibre to Fibre Channel Channel Fabric Fabric
Key: FC-0 - Fibre Channel Physical Media Layer
FC-1 - Fibre Channel Encode and Decode Layer
FC-2 - Fibre Channel Framing and Flow Control Layer
TCP - Transmission Control Protocol
IP - Internet Protocol
LINK - IP Link Layer
PHY - IP Physical Layer
Key: FC-0 - Fibre Channel Physical Media Layer FC-1 - Fibre Channel Encode and Decode Layer FC-2 - Fibre Channel Framing and Flow Control Layer TCP - Transmission Control Protocol IP - Internet Protocol LINK - IP Link Layer PHY - IP Physical Layer
Figure 1: FCIP Protocol Stack Model
Figure 1: FCIP Protocol Stack Model
Note that the objective of the FCIP Protocol is to create and maintain one or more FCIP Links to transport data.
Note that the objective of the FCIP Protocol is to create and maintain one or more FCIP Links to transport data.
Rajagopal, et al. Standards Track [Page 9] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 9] RFC 3821 FCIP July 2004
5.2. FCIP Link
5.2. FCIP Link
The FCIP Link is the basic unit of service provided by the FCIP Protocol to an FC Fabric. As shown in figure 2, an FCIP Link connects two portions of an FC Fabric using an IP Network as a transport to form a single FC Fabric.
The FCIP Link is the basic unit of service provided by the FCIP Protocol to an FC Fabric. As shown in figure 2, an FCIP Link connects two portions of an FC Fabric using an IP Network as a transport to form a single FC Fabric.
/\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ IP / \ FC /
/ Fabric \=========/ Network \=========/ Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/
| |
|<--------- FCIP Link -------->|
/\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\ \ FC / \ IP / \ FC / / Fabric \=========/ Network \=========/ Fabric \ \/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/ | | |<--------- FCIP Link -------->|
Figure: 2 FCIP Link Model
Figure: 2 FCIP Link Model
At the points where the ends of the FCIP Link meet portions of the FC Fabric, an FCIP Entity (see section 5.4) combines with an FC Entity as described in section 5.3 to serve as the interface between FC and IP.
At the points where the ends of the FCIP Link meet portions of the FC Fabric, an FCIP Entity (see section 5.4) combines with an FC Entity as described in section 5.3 to serve as the interface between FC and IP.
An FCIP Link SHALL contain at least one TCP Connection and MAY contain more than one TCP Connection. The endpoints of a single TCP Connection are FCIP Data Engines (see section 5.6). The endpoints of a single FCIP Link are FCIP Link Endpoints (see section 5.5).
An FCIP Link SHALL contain at least one TCP Connection and MAY contain more than one TCP Connection. The endpoints of a single TCP Connection are FCIP Data Engines (see section 5.6). The endpoints of a single FCIP Link are FCIP Link Endpoints (see section 5.5).
Rajagopal, et al. Standards Track [Page 10] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 10] RFC 3821 FCIP July 2004
5.3. FC Entity
5.3. FC Entity
An implementation that tunnels an FC Fabric through an IP Network MUST combine an FC Entity with an FCIP Entity (see section 5.4) to form a complete interface between the FC Fabric and IP Network as shown in figure 3. An FC Fabric Entity may contain multiple instances of the FC/FCIP Entity pair shown on either the right-hand or left-hand side of figure 3.
An implementation that tunnels an FC Fabric through an IP Network MUST combine an FC Entity with an FCIP Entity (see section 5.4) to form a complete interface between the FC Fabric and IP Network as shown in figure 3. An FC Fabric Entity may contain multiple instances of the FC/FCIP Entity pair shown on either the right-hand or left-hand side of figure 3.
|<--------- FCIP Link -------->|
| |
+----------+ /\/\/\/\/\/\ +----------+
| FCIP | \ IP / | FCIP |
| Entity |=========/ Network \=========| Entity |
+----------+ \/\/\/\/\/\/ +----------+
| FC | | FC |
| Entity | | Entity |
+----------+ +----------+
| |
/\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ FC /
/ Fabric \ / Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/
|<--------- FCIP Link -------->| | | +----------+ /\/\/\/\/\/\ +----------+ | FCIP | \ IP / | FCIP | | Entity |=========/ Network \=========| Entity | +----------+ \/\/\/\/\/\/ +----------+ | FC | | FC | | Entity | | Entity | +----------+ +----------+ | | /\/\/\/\/\/\ /\/\/\/\/\/\ \ FC / \ FC / / Fabric \ / Fabric \ \/\/\/\/\/\/ \/\/\/\/\/\/
Figure 3: Model for Two Connected FC/FCIP Entity Pairs
Figure 3: Model for Two Connected FC/FCIP Entity Pairs
In general, the combination of an FCIP Link and two FC/FCIP Entity pairs is intended to provide a non-Fibre Channel backbone transport between Fibre Channel components. For example, this combination can be used to function as the hard-wire connection between two Fibre Channel switches.
In general, the combination of an FCIP Link and two FC/FCIP Entity pairs is intended to provide a non-Fibre Channel backbone transport between Fibre Channel components. For example, this combination can be used to function as the hard-wire connection between two Fibre Channel switches.
The interface between the FC and FCIP Entities is implementation specific. The functional requirements placed on an FC Entity by this specification are listed in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
The interface between the FC and FCIP Entities is implementation specific. The functional requirements placed on an FC Entity by this specification are listed in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
Rajagopal, et al. Standards Track [Page 11] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 11] RFC 3821 FCIP July 2004
5.4. FCIP Entity
5.4. FCIP Entity
The model for an FCIP Entity is shown in figure 4.
The model for an FCIP Entity is shown in figure 4.
.......................................................
: FCIP Entity :
: :
: +-----------+ :
: | FCIP | :
: |Control and|------------------------------------+ :
: | Services | | :
: | Module | | :
: +-----------+ | :
: | +--------------------+ | :
: | +-------+--------------------+|----+ | :
: | |+-----+--------------------+|----+| | :
: | ||+----| FCIP Link Endpoint |----+|| | :
: | ||| +--------------------+ ||| | :
:.............................................|||.....:
| ||| ||| |
| ||| ||| o<--+
| ||| unique TCP ||| | |
| ||| connections-->||| | |
| ||| ||| | |
+----------+ /\/\/\/\/\/\ |
| FC | \ IP / |
| Entity | / Network \ |
+----------+ \/\/\/\/\/\/ |
| |
/\/\/\/\/\/\ +------------------+
\ FC / +->TCP port for
/ Fabric \ incoming
\/\/\/\/\/\/ connections
....................................................... : FCIP実体: : : : +-----------+ : : | FCIP| : : |そしてコントロール。|------------------------------------+ : : | サービス| | : : | モジュール| | : : +-----------+ | : : | +--------------------+ | : : | +-------+--------------------+|----+ | : : | |+-----+--------------------+|----+| | : : | ||+----| FCIPリンク終点|----+|| | : : | ||| +--------------------+ ||| | : :.............................................|||.....: | ||| ||| | | ||| ||| o<--+ | ||| ユニークなTCP||| | | | ||| 接続-->|、|、|、|、|、| ||| ||| | | +----------+ /\/\/\/\/\/\ | | FC| \IP/| | 実体| /ネットワーク\| +----------+ \/\/\/\/\/\/ | | | /\/\/\/\/\/\ +------------------+ TCPが/織物\入って来る\/\/\/\/\/\/接続のために移植する\FC/+->。
Figure 4: FCIP Entity Model
図4: FCIP実体モデル
The FCIP Entity receives TCP connect requests on behalf of the FCIP_LEPs that it manages. In support of this, the FCIP Entity is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address. An FC Fabric to IP Network interface product SHALL provide each FC/FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7).
FCIP Entityは受信します。TCPはFCIP_LEPsを代表した管理するという要求を接続します。 これを支持して、FCIP EntityはTCPコネクションズを形成するのに使用される少なくとも1つのTCPポート/IP Address組み合わせの単独の持ち主です。 TCPポートは与えられたIP AddressのFCIPのよく知られているポートであるかもしれません。 SHALLがそれぞれのFC/FCIP Entity組を供給するIP Networkインタフェース製品へのFC Fabricは製品にFC Fabric Entity World Wide IdentifierとFC/FCIP Entity Identifierのユニークな組み合わせで値を含みました(セクション7を見てください)。
An FCIP Entity contains an FCIP Control and Services Module to control FCIP link initialization, FCIP link dissolution, and to provide the FC Entity with an interface to key IP Network features.
FCIP EntityはFCIPリンク初期化、FCIPリンク溶解を制御して、インタフェースをFC Entityに提供するFCIP ControlとServices Moduleを主要なIP Networkの特徴に含んでいます。
Rajagopal, et al. Standards Track [Page 12] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[12ページ]。
The interfaces to the IP Network features are implementation specific, however, REQUIRED TCP/IP functional support is specified in this document, including:
IP Networkの特徴へのインタフェースが実現特有である、しかしながら、REQUIRED TCP/IPの機能的なサポートは本書では指定されます、である:
- TCP Connections - see section 8 - Security - see section 9 - Performance - see section 10 - Dynamic Discovery - see section 8.1.2.2
- TCPコネクションズ--セクション8(セキュリティ)が、セクション9(パフォーマンス)が、セクション10(ダイナミックなディスカバリー)がセクション8.1.2を見るのを見るのを見るのを見てください、.2
The FCIP Link Endpoints in an FCIP Entity provide the FC Frame encapsulation and transmission features of FCIP.
FCIP EntityのFCIP Link EndpointsはFCIPのFC Frameカプセル化とトランスミッション機能を提供します。
5.5. FCIP Link Endpoint (FCIP_LEP)
5.5. FCIPリンク終点(FCIP_LEP)
As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data Engine for each TCP Connection in the FCIP Link.
5が中で計算するのが示されるように、FCIP Link EndpointはFCIP Linkに各TCP Connectionあたり1FCIP Data Engineを含んでいます。
................................................
: FCIP Link Endpoint :
: +------------------+ :
: +-------+------------------+|----+ :
: |+-----+------------------+|----+| :
: ||+----| FCIP Data Engine |----+|| :
: ||| +------------------+ ||| :
:..............................................:
||| |||
+----------+ /\/\/\/\/\/\
| FC | \ IP /
| Entity | / Network \
+----------+ \/\/\/\/\/\/
|
/\/\/\/\/\/\
\ FC /
/ Fabric \
\/\/\/\/\/\/
................................................ : FCIPは終点をリンクします: : +------------------+ : : +-------+------------------+|----+ : : |+-----+------------------+|----+| : : ||+----| FCIPデータエンジン|----+|| : : ||| +------------------+ ||| : :..............................................: ||| ||| +----------+ /\/\/\/\/\/\ | FC| \IP/| 実体| /ネットワーク\+----------+ \/\/\/\/\/\/ | /\/\/\/\/\/\\FC//織物\\/\/\/\/\/\/
Figure 5: FCIP Link Endpoint Model
図5: FCIPリンク終点モデル
Each time a TCP Connection is formed with a new FC/FCIP Entity pair (including all the actions described in section 8.1), the FCIP Entity SHALL create a new FCIP Link Endpoint containing one FCIP Data Engine.
その都度、TCP Connectionは新しいFC/FCIP Entity組と共に形成されて(セクション8.1で説明されたすべての動作を含んでいます)、FCIP Entity SHALLは1FCIP Data Engineを含む新しいFCIP Link Endpointを作成します。
An FCIP_LEP is a transparent data translation point between an FC Entity and an IP Network. A pair of FCIP_LEPs communicating over one or more TCP Connections create an FCIP Link to join two islands of an FC Fabric, producing a single FC Fabric.
FCIP_LEPはFC EntityとIP Networkの間の見え透いたデータ変換ポイントです。 1TCPのコネクションズを伝える1組のFCIP_LEPsはFC Fabricの2つの島を接合するためにFCIP Linkを作成します、独身のFC Fabricを生産して。
Rajagopal, et al. Standards Track [Page 13] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[13ページ]。
The IP Network over which the two FCIP_LEPs communicate is not aware of the FC payloads that it is carrying. Likewise, the FC End Nodes connected to the FC Fabric are unaware of the TCP/IP based transport employed in the structure of the FC Fabric.
2FCIP_LEPsが交信するIP Networkはそれが運ばれる予定であるのをFCペイロードを意識していません。 同様に、FC Fabricに接続されたFC End NodesはFC Fabricの構造で使われたTCP/IPに基づいている輸送に気づきません。
An FCIP_LEP uses normal TCP based flow control mechanisms for managing its internal resources and matching them with the advertised TCP Receiver Window Size (see sections 8.3.2, 8.5). An FCIP_LEP MAY communicate with its local FC Entity counterpart to coordinate flow control.
FCIP_LEPは、社内資源を管理して、広告を出しているTCP Receiver Window Sizeにそれらを合わせるのに正常なTCPベースのフロー制御メカニズムを使用します(セクション8.3.2、8.5を見てください)。 LEP MAYがフロー制御を調整するために地元のFC Entity対応者と伝えるFCIP_。
5.6. FCIP Data Engine (FCIP_DE)
5.6. FCIPデータエンジン(FCIP_DE)
The model for one of the multiple FCIP_DEs that MAY be present in an FCIP_LEP is shown in figure 6.
複数のFCIP_LEPに存在するかもしれないFCIP_DEsの1つのモデルは6が中で計算するのが示されます。
+--------------------------------+
| |
F |-+ +------------------+ +-|
C |p| | Encapsulation | |p| N
-->|1|--->| Engine |--->|2|--> e
E |-+ +------------------+ +-| t
n | | I w
t |-+ +------------------+ +-| P o
i |p| | De-Encapsulation | |p| r
t <--|4|<---| Engine |<---|3|<-- k
y |-+ +------------------+ +-|
| |
+--------------------------------+
+--------------------------------+ | | F|-+ +------------------+ +-| C|p| | カプセル化| |p| N-->|1|、-、--、>| エンジン|、-、--、>|2|-->e E|-+ +------------------+ +-| t n| | I w t|-+ +------------------+ +-| P o i|p| | 反-カプセル化| |p| r t<--|4| <、-、--、| エンジン| <、-、--、|3| <-- k y|-+ +------------------+ +-| | | +--------------------------------+
Figure 6: FCIP Data Engine Model
図6: FCIPデータエンジンモデル
Data enters and leaves the FCIP_DE through four portals (p1 - p4). The portals do not process or examine the data that passes through them. They are only the named access points where the FCIP_DE interfaces with the external world. The names of the portals are as follows:
データは、4つの入り口(p1--p4)を通ってFCIP_をDEに入れて、発ちます。 入り口は、それらを通り抜けるデータを、処理もしませんし、調べもしません。 唯一のそれらはFCIP_DEが外界に連結する命名されたアクセスポイントです。 入り口の名前は以下の通りです:
p1) FC Frame Receiver Portal - The interface through which an FC
Frame and time stamp enters an FCIP_DE from the FC Entity.
p1) FC Frame Receiver Portal--FC Frameと時間が押し込むインタフェースはFC EntityからFCIP_DEに入ります。
p2) Encapsulated Frame Transmitter Portal - The TCP interface through
which an FCIP Frame is transmitted to the IP Network by an
FCIP_DE.
p2) 要約のFrame Transmitter Portal--FCIP FrameがFCIP_DEによってIP Networkに伝えられるTCPは連結します。
p3) Encapsulated Frame Receiver Portal - The TCP interface through
which an FCIP Frame is received from the IP Network by an
FCIP_DE.
p3) 要約のFrame Receiver Portal--FCIP FrameがFCIP_DEによってIP Networkから受け取られるTCPは連結します。
Rajagopal, et al. Standards Track [Page 14] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[14ページ]。
p4) FC Frame Transmitter Portal - The interface through which a
reconstituted FC Frame and time stamp exits an FCIP_DE to the FC
Entity.
p4) FC Frame Transmitter Portal--再編成されたFC Frameと時間が押し込むインタフェースはFCIP_DEをFC Entityに出ます。
The work of the FCIP_DE is done by the Encapsulation and De- Encapsulation Engines. The Engines have two functions:
EncapsulationとDeカプセル化EnginesはFCIP_DEの仕事を完了しています。 Enginesには、2つの機能があります:
1) Encapsulating and de-encapsulating FC Frames using the
encapsulation format described in FC Frame Encapsulation [19] and
in section 5.6.1 of this document, and
1) そしてカプセル化形式を使用することでFC Framesを要約して、反-要約するとこの.1通のドキュメントがFC Frame Encapsulation[19]とセクション5.6で説明された。
2) Detecting some data transmission errors and performing minimal
error recovery as described in section 5.6.2.
2) セクション5.6.2で説明されるようにいくつかのデータ伝送誤りを検出して、最小量のエラー回復を実行します。
Data flows through a pair of IP Network connected FCIP_DEs in the following seven steps:
1組のIP Networkを通したデータフローは以下の7ステップでFCIP_DEsを接続しました:
1) An FC Frame and time stamp arrives at the FC Frame Receiver Portal
and is passed to the Encapsulation Engine. The FC Frame is
assumed to have been processed by the FC Entity according to the
applicable FC rules and is not validated by the FCIP_DE. If the
FC Entity is in the Unsynchronized state with respect to a time
base as described in the FC Frame Encapsulation [19]
specification, the time stamp delivered with the FC Frame SHALL be
zero.
1) スタンプがFC Frame Receiver Portalに到着して、Encapsulation Engineに渡されるFC Frameと時。 FC Frameは適切なFC規則に従ってFC Entityによって処理されたと思われて、FCIP_DEによって有効にされません。 時間ベースに関してFC Entityが説明されるようにUnsynchronized状態にあるなら、FC Frame Encapsulation[19]仕様、FC Frame SHALLと共に届けられたタイムスタンプではゼロになってください。
2) In the Encapsulation Engine, the encapsulation format described in
FC Frame Encapsulation [19] and in section 5.6.1 of this document
SHALL be applied to prepare the FC Frame and associated time stamp
for transmission over the IP Network.
2) Encapsulation Engine、形式がFC Frame Encapsulation[19]とこの.1セクション5.6ドキュメントSHALLで説明したカプセル化では、適用されて、IP Networkの上のトランスミッションのためにFC Frameと関連タイムスタンプを準備してください。
3) The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL be
passed to the Encapsulated Frame Transmitter Portal where it SHALL
be inserted in the TCP byte stream.
3) 全体の要約のFC Frame(通称FCIP Frame) SHALL、Encapsulated Frame Transmitter Portalに通過されてください、どこ、それ、SHALL、TCPバイト・ストリームに挿入されてくださいか。
4) Transmission of the FCIP Frame over the IP Network follows all the
TCP rules of operation. This includes, but is not limited to, the
in-order delivery of bytes in the stream, as specified by TCP [6].
4) IP Networkの上のFCIP Frameのトランスミッションは操作のすべてのTCP規則に従います。 含んでいますが、これが制限されない、TCP[6]によって指定されるようなオーダーにおける、流れにおける、バイトの配送。
5) The FCIP Frame arrives at the partner FCIP Entity where it enters
the FCIP_DE through the Encapsulated Frame Receiver Portal and is
passed to the De-Encapsulation Engine for processing.
5) FCIP FrameはそれがEncapsulated Frame Receiver Portalを通してFCIP_DEに入れて、処理のためにDe-カプセル化Engineに通過されるパートナーFCIP Entityに到着します。
6) The De-Encapsulation Engine SHALL validate the incoming TCP byte
stream as described in section 5.6.2.2 and SHALL de-encapsulate
the FC Frame and associated time stamp according to the
encapsulation format described in FC Frame Encapsulation [19] and
in section 5.6.1 of this document.
6) セクション5.6で説明されて、FC Frame Encapsulation[19]とこの.1通のセクション5.6ドキュメントで説明されたカプセル化形式に応じて.2の.2とSHALLが反-FC Frameと関連タイムスタンプをカプセルに入れるとき、De-カプセル化Engine SHALLは入って来るTCPバイト・ストリームを有効にします。
Rajagopal, et al. Standards Track [Page 15] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[15ページ]。
7) In the absence of errors, the de-encapsulated FC Frame and time
stamp SHALL be passed to the FC Frame Transmitter Portal for
delivery to the FC Entity. Error handling is discussed in section
5.6.2.2.
7) 誤り、反-要約されたFC Frame、およびタイムスタンプSHALLが不在のとき、FC Entityへの配送のためにFC Frame Transmitter Portalに通過されてください。 セクション5.6.2で.2にエラー処理について議論します。
Every FC Frame that arrives at the FC Frame Receiver Portal SHALL be transmitted on the IP Network as described in steps 1 through 4 above. In the absence of errors, data bytes arriving at the Encapsulated Frame Receiver Portal SHALL be de-encapsulated and forwarded to the FC Frame Transmitter Portal as described in steps 5 through 7.
それはFC Frame Receiver Portal SHALLに到着します。あらゆるFC Frame、上の4を通したステップ1で説明されるようにIP Networkで伝えられてください。 誤り、Encapsulated Frame Receiver Portal SHALLに到着するデータ・バイトがないとき、ステップ5〜7で説明されるように反-要約にされてFC Frame Transmitter Portalに送ってください。
5.6.1. FCIP Encapsulation of FC Frames
5.6.1. FCフレームのFCIPカプセル化
The FCIP encapsulation of FC Frames employs FC Frame Encapsulation [19].
FC FramesのFCIPカプセル化はFC Frame Encapsulation[19]を使います。
The features from FC Frame Encapsulation that are unique to individual protocols SHALL be applied as follows for the FCIP encapsulation of FC Frames.
FC FramesのFCIPカプセル化のために以下の通り適用されていて、個々のプロトコルSHALLにユニークなFC Frame Encapsulationからの特徴。
The Protocol# field SHALL contain 1 in accordance with the IANA Considerations annex of FC Frame Encapsulation [19].
FC Frame Encapsulation[19]のIANA Considerations別館に従って、プロトコル#分野SHALLは1を含んでいます。
The Protocol Specific field SHALL have the format shown in figure 7. Note: the word numbers in figure 7 are relative to the complete FC Frame Encapsulation header, not to the Protocol Specific field.
プロトコルSpecific分野SHALLには、7が中で計算するのが示された書式があります。 以下に注意してください。 7図の単語番号はプロトコルSpecific分野ではなく、完全なFC Frame Encapsulationヘッダーに比例しています。
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|
+---------------------------------------------------------------+
1| replication of encapsulation word 0 |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
+---------------+---------------+---------------+---------------+
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| +---------------------------------------------------------------+ 1| カプセル化Word0の模写| +---------------+---------------+---------------+---------------+ 2| pFlags| 予約されます。| -pFlags| -予約されます。| +---------------+---------------+---------------+---------------+
Figure 7: FCIP Usage of FC Frame Encapsulation Protocol Specific field
図7: SpecificがさばくFC Frame EncapsulationプロトコルのFCIP Usage
Word 1 of the Protocol Specific field SHALL contain an exact copy of word 0 in FC Frame Encapsulation [19].
プロトコルSpecific分野SHALLのWord1はFC Frame Encapsulation[19]にWord0の正確なコピーを含んでいます。
The pFlags (protocol specific flags) field provides information about the protocol specific usage of the FC Encapsulation Header. Figure 8 shows the defined pFlags bits.
pFlags(特定の旗について議定書の中で述べる)分野はFC Encapsulation Headerのプロトコルの特定の使用法の情報を提供します。 エイト環は定義されたpFlagsビットを見せています。
Rajagopal, et al. Standards Track [Page 16] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[16ページ]。
|----------------Bit--------------------| | | | 0 1 2 3 4 5 6 7 | +----+-----------------------------+----+ | Ch | Reserved | SF | +----+-----------------------------+----+
|----------------ビット--------------------| | | | 0 1 2 3 4 5 6 7 | +----+-----------------------------+----+ | Ch| 予約されます。| SF| +----+-----------------------------+----+
Figure 8: pFlags Field Bits
エイト環: pFlags分野ビット
The SF (Special Frame) bit indicates whether the FCIP Frame is an encapsulated FC Frame or an FSF (FCIP Special Frame, see section 7). When the FCIP Frame contains an encapsulated FC Frame, the SF bit SHALL be 0. When the FCIP Frame is an FSF, the SF bit SHALL be 1.
SF(特別なFrame)ビットは、FCIP Frameが要約のFC FrameかそれともFSF(FCIP Special Frame、セクション7を見る)であるかを示します。 FCIP Frameが要約のFC Frameを含むとき、SFはSHALLに噛み付きました。0になってください。 FCIP FrameによるFSF、SFがSHALLに噛み付いたということであるときには1になってください。
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection and only one FSF SHALL be transmitted in each direction at that time (see section 8.1). After that all FCIP Frames SHALL have the SF bit set to 0.
FSF SHALL、最初のバイトが伝えられたコネが各指示であったならその時新たに形成されたTCP ConnectionとあるFSF SHALLだけに関する各方向に伝わったように(セクション8.1を見てください)単に送ってください。 すべてのFCIP Frames SHALLにはSFビットがあるのが0にセットした後に
The Ch (Changed) bit indicates whether an echoed FSF has been intentionally altered (see section 8.1.3). The Ch bit SHALL be 0 unless the FSF bit is 1. When the initial TCP Connection FSF is sent, the Ch bit SHALL be 0. If the recipient of a TCP connect request echoes the FSF without any changes, then the Ch bit SHALL continue to be 0. If the recipient of a TCP connect request alters the FSF before echoing it, then the Ch bit SHALL be changed to 1.
Ch(変える)ビットは、反響しているFSFが故意に変更されたかどうかを(セクション8.1.3を見てください)示します。 ChはSHALLに噛み付きました。FSFビットが1でないなら、0になってください。 初期であるときに、TCP Connection FSFを送って、ChはSHALLに噛み付きました。0になってください。 TCPの受取人が接続するなら、要求は少しも変化なしでFSFを反響します、そして、ChビットSHALLがずっと0歳です。 TCPの受取人が接続するなら、それを反響する前に要求はFSFを変更します、次に、ChがSHALLに噛み付きました。1に変えます。
The -pFlags field SHALL contain the ones complement of the contents of the pFlags field.
-pFlags分野SHALLはpFlags分野のコンテンツのもの補数を含んでいます。
Rajagopal, et al. Standards Track [Page 17] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[17ページ]。
Table 1 summarizes the usage of the pFlags SF and Ch bits.
テーブル1はpFlags SFとChビットの使用法をまとめます。
+----+----+------------+--------------------------------------+ | | | Originated | | | SF | Ch | or Echoed | Validity/Description | +----+----+------------+--------------------------------------+ | 0 | 0 | n/a | Encapsulated FC Frame | +----+----+------------+--------------------------------------+ | 0 | 1 | n/a | Always Illegal | +----+----+------------+--------------------------------------+ | 1 | 0 | Originated | Originated FSF | +----+----+------------+--------------------------------------+ | 1 | 1 | Originated | Always Illegal | +----+----+------------+--------------------------------------+ | 1 | 0 | Echoed | Echoed FSF without changes | +----+----+------------+--------------------------------------+ | 1 | 1 | Echoed | Echoed FSF with changes | +----+----+------------+--------------------------------------+ | Note 1: Echoed FSFs may contain changes resulting from | | transmission errors, necessitating the comparison between | | sent and received FSF bytes by the FSF originator described | | in section 8.1.2.3. | | | | Note 2: Column positions in this table do not reflect the | | bit positions of the SF and Ch bits in the pFlags field. | +-------------------------------------------------------------+
+----+----+------------+--------------------------------------+ | | | 由来します。| | | SF| Ch| または、反響にされる| 正当性/記述| +----+----+------------+--------------------------------------+ | 0 | 0 | なし| 要約のFCフレーム| +----+----+------------+--------------------------------------+ | 0 | 1 | なし| いつも不法です。| +----+----+------------+--------------------------------------+ | 1 | 0 | 由来します。| 溯源されたFSF| +----+----+------------+--------------------------------------+ | 1 | 1 | 由来します。| いつも不法です。| +----+----+------------+--------------------------------------+ | 1 | 0 | 反響されます。| 変化のない反響しているFSF| +----+----+------------+--------------------------------------+ | 1 | 1 | 反響されます。| 変化を伴う反響しているFSF| +----+----+------------+--------------------------------------+ | 注意1: 反響しているFSFsは変化の結果になることを含むかもしれません。| | 間に比較を必要とする伝送エラー| | 説明されたFSF創始者による送られて容認されたFSFバイト| | 中では、8.1に.3に.2を区分してください。 | | | | 注意2: このテーブルのコラム位置は反射しません。| | pFlags分野のSFとChビットのビット位置。 | +-------------------------------------------------------------+
Table 1: pFlags SF and Ch bit usage summary
テーブル1: pFlags SFとChは用法概要に噛み付きました。
The Reserved pFlags bits SHALL be 0.
Reserved pFlagsビットSHALL、0になってください。
The Reserved field (bits 23-16 in word 2): SHALL contain 0.
Reservedは(Word2によるビット23-16)をさばきます: SHALLは0を含んでいます。
The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or 0xFF).
予約された分野(Word2によるビット7-0): SHALLは255(または、0xFF)を含んでいます。
The CRCV (CRC Valid) Flag SHALL be set to 0.
CRCV(CRC Valid)はSHALLに旗を揚げさせます。0に設定されます。
The CRC field SHALL be set to 0.
CRCはSHALLをさばきます。0に、用意ができています。
In FCIP, the SOF and EOF codes listed as Class 2, Class 3, and Class 4 in the FC Frame Encapsulation [19] are legal.
FCIPでは、FC Frame Encapsulation[19]のClass2、Class3、およびClass4が法的であるので、SOFとEOFコードは記載しました。
Rajagopal, et al. Standards Track [Page 18] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[18ページ]。
5.6.2. FCIP Data Engine Error Detection and Recovery
5.6.2. FCIPデータエンジン誤り検出と回復
5.6.2.1. TCP Assistance With Error Detection and Recovery
5.6.2.1. 誤り検出と回復とのTCP支援
TCP [6] requires in order delivery, generation of TCP checksums, and checking of TCP checksums. Thus, the byte stream passed from TCP to the FCIP_LEP will be in order and free of errors detectable by the TCP checksum. The FCIP_LEP relies on TCP to perform these functions.
TCP[6]はTCPチェックサムを注文配送、TCPチェックサムの世代で必要であり、チェックします。その結果、TCPからFCIP_LEPまで通過されたバイト・ストリームは、TCPチェックサムで検出可能な誤りを整然として持たないでしょう。 FCIP_LEPは、これらの機能を実行するためにTCPを当てにします。
5.6.2.2. Errors in FCIP Headers and Discarding FCIP Frames
5.6.2.2. FCIPヘッダーとFCIPフレームを捨てることにおける誤り
Bytes delivered through the Encapsulated Frame Receiver Portal that are not correctly delimited as defined by the FC Frame Encapsulation [19] are considered to be in error.
FC Frame Encapsulation[19]によって定義されるように正しく区切られないEncapsulated Frame Receiver Portalを通して送られたバイトが間違っていると考えられます。
The failure of the Protocol# and Version fields in the FCIP Frame header to contain the values defined for an FCIP Frame SHALL be considered an error.
プロトコル#とバージョンの失敗は、FCIP FrameヘッダーでFCIP Frame SHALLのために定義された値を含むのをさばきます。誤りであると考えられます。
Further, some errors in the encapsulation will result in the FCIP_DE losing synchronization with the FC Frames in the byte stream entering through the Encapsulated Frame Receiver Portal.
さらに、カプセル化におけるいくつかの誤りがバイト・ストリームにおけるEncapsulated Frame Receiver Portalを通して入るFC FramesとのFCIP_DEの損をしている同期をもたらすでしょう。
The Frame Length field in the FC Frame Encapsulation header is used to determine where in the data stream the next FC Encapsulated Header is located. The following tests SHALL be performed to verify synchronization with the byte stream entering the Encapsulated Frame Receiver Portal, and synchronization SHALL be considered lost if any of the tests fail:
FC Frame EncapsulationヘッダーのFrame Length分野は、データ・ストリームでは、次のFC Encapsulated Headerがどこに位置しているかを決定するのに使用されます。 以下はSHALLをテストします。実行されて、テストのどれかが失敗するなら、Encapsulated Frame Receiver Portalに入るバイト・ストリームと無くなると考えられる同期SHALLとの同期について確かめてください:
1) Frame Length field validation -- 15 < Frame Length < 545;
1) フレームLength分野合法化--15 <Frame Length<545。
2) Comparison of Frame Length field to its ones complement; and
2) もの補数へのFrame Length分野の比較。 そして
3) A valid EOF is found in the word preceding the start of the next
FCIP header as indicated by the Frame Length field, to be tested
as follows:
3) 有効なEOFはFrame Length分野によって示されて、以下の通りテストされるように次のFCIPヘッダーの始まりに先行する単語で見つけられます:
1) Bits 24-31 and 16-23 contain identical legal EOF values (the
list of legal EOF values is in the FC Frame Encapsulation
[19]); and
1) ビット24-31と16-23は同じ法的なEOF値を含んでいます。(法的なEOF値のリストがFC Frame Encapsulation[19])にあります。 そして
2) Bits 8-15 and 0-7 contain the ones complement of the EOF value
found in bits 24-31.
2) ビット8-15と0-7 ビット24-31で見つけられたEOF価値のもの補数を含んでください。
Note: The range of valid Frame Length values is derived as follows. The FCIP Frame header is seven words, one word each is required for the encoded SOF and EOF values, the FC Frame header is six words, and
以下に注意してください。 有効なFrame Length値の範囲は以下の通り引き出されます。 そしてFCIP Frameヘッダーが7つの単語、それぞれがコード化されたSOFとEOF値に必要であるという1つの単語である、FC Frameヘッダーが6つの単語である。
Rajagopal, et al. Standards Track [Page 19] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[19ページ]。
the FC CRC requires one word, yielding a base Frame Length of 16 (7+1+1+6+1) words, if no FC Payload is present. Since the FC Payload is optional, any Frame Length value greater than 15 is valid. The maximum FC Payload size is 528 words, meaning that any Frame Length value up to and including 544 (528+16) is valid.
FC CRCは1つの単語を必要とします、16(7+1+1+6+1)の単語のベースFrame Lengthをもたらして、どんなFC有効搭載量も存在していないなら。 FC有効搭載量が任意であるので、どんなFrame Length値より多くの15も有効です。 最大のFC有効搭載量サイズは528の単語です、どんなFrame Lengthも544を含めて評価する意味、(528、+16、)、有効です。
If synchronization is lost, the FC Frame SHALL NOT be forwarded on to the FC Entity and further recovery SHALL be handled as defined by section 5.6.2.3.
失われた同期、FC Frame SHALLがFC Entityに送られて、より遠い回復SHALLでないなら、セクション5.6.2で.3を定義するとき、扱われてください。
In addition to the tests above, the validity and positioning of the following FCIP Frame information SHOULD be used to detect encapsulation errors that may or may not affect synchronization:
以下のFCIP Frame情報SHOULDの上のテスト、正当性、および位置決めに加えて使用されて、同期に影響するかもしれないカプセル化誤りを検出してください:
a) Protocol# ones complement field (1 test);
b) Version ones complement field (1 test);
c) Replication of encapsulation word 0 in word 1 (1 test);
d) Reserved field and its ones complement (2 tests);
e) Flags field and its ones complement (2 tests);
f) CRC field is equal to zero (1 test);
g) SOF fields and ones complement fields (4 tests);
h) Format and values of FC header (1 test);
i) CRC of FC Frame (2 tests);
j) FC Frame Encapsulation header information in the next FCIP
Frame (1 test).
a) プロトコル#もの補数が(1つのテスト)をさばきます。 b) ものバージョン補数が(1つのテスト)をさばきます。 c) Word1(1つのテスト)における、カプセル化Word0の模写。 d) 予約された分野とそのもの補数(2つのテスト)。 e) 分野とそのもの補数(2つのテスト)に旗を揚げさせます。 f) CRC分野は(1つのテスト)のゼロを合わせるために等しいです。 g) SOF分野ともの補数の分野(4つのテスト)。 h) FCヘッダー(1つのテスト)の形式と値。 i) FC Frame(2つのテスト)のCRC。 j) 次のFCIP Frame(1つのテスト)のFC Frame Encapsulationヘッダー情報。
At least 3 of the 16 tests listed above SHALL be performed. Failure of any of the above tests actually performed SHALL indicate an encapsulation error and the FC Frame SHALL NOT be forwarded on to the FC Entity. Further, such errors SHOULD be considered carefully, since some may be synchronization errors.
少なくとも16のテストのうち3はSHALLの上に記載しました。実行されます。 実際に実行された上のテストSHALLのどれかの失敗は、カプセル化誤りとFC Frame SHALLがFC Entityに送られないのを示します。 何かがそうするかもしれないのでさらに、同期誤りになってくださいそのような誤りSHOULDが慎重に考えられて。
Whenever an FCIP_DE discards bytes delivered through the Encapsulated Frame Receiver Portal, it SHALL cause the FCIP Entity to notify the FC Entity of the condition and provide a suitable description of the reason bytes were discarded.
FCIP_DEがEncapsulated Frame Receiver Portalを通して送られたバイトを捨てて、それがSHALLであるときはいつも、FCIP Entityが状態についてFC Entityに通知して、バイトが捨てられた理由の適当な記述を提供することを引き起こしてください。
The burden for recovering from discarded data falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
捨てられたデータから回復するための負担は、FC FabricのFC Entityと他の部品に落ちて、この仕様の範囲の外にあります。
Rajagopal, et al. Standards Track [Page 20] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[20ページ]。
5.6.2.3. Synchronization Failures
5.6.2.3. 同期失敗
If an FCIP_DE determines that it cannot find the next FCIP Frame header in the byte stream entering through the Encapsulated Frame Receiver Portal, the FCIP_DE SHALL do one of the following:
FCIP_DEが、バイト・ストリームにおける次のFCIP FrameヘッダーがEncapsulated Frame Receiver Portalを通して入っているのを見つけることができないことを決定するなら、FCIP_DE SHALLは以下の1つをします:
a) close the TCP Connection [6] [7] and notify the FC Entity with the
reason for the closure;
a) TCP Connection[6][7]を閉じてください、そして、閉鎖の理由でFC Entityに通知してください。
b) recover synchronization by searching the bytes delivered by the
Encapsulated Frame Receiver Portal for a valid FCIP Frame header
having the correct properties (see section 5.6.2.2), and
discarding bytes delivered by the Encapsulated Frame Receiver
Portal until a valid FCIP Frame header is found; or
b)は、正しい特性を持っている有効なFCIP FrameヘッダーのためにEncapsulated Frame Receiver Portalによって送られたバイトを捜すことによって、同期を回復します。(有効なFCIP Frameヘッダーが見つけられるまでセクション5.6.2.2、)および捨てるバイトがEncapsulated Frame Receiver Portalによって送られるのを見てください。 または
c) attempt to recover synchronization as described in b) and if
synchronization cannot be recovered, close the TCP Connection as
described in a), including notification of the FC Entity with the
reason for the closure.
c) b)で説明されるように同期を回復するのを試みてください、そして、同期を回復できないなら、a)で説明されるようにTCP Connectionを閉じてください、閉鎖の理由があるFC Entityの通知を含んでいて。
If the FCIP_DE attempts to recover synchronization, the resynchronization algorithm used SHALL meet the following requirements:
同期、再同期アルゴリズムを回復するFCIP_DE試みであるなら、中古のSHALLは以下の必要条件を満たします:
a) discard or identify with an EOFa (see appendix section F.1) those
FC Frames and fragments of FC Frames identified before
synchronization has again been completely verified. The number of
FC Frames not forwarded may vary based on the algorithm used;
a) 捨てるか、または同期が再び完全に確かめられる前に特定されたFC FramesのそれらのFC Framesと断片をEOFa(付録部分F.1を見る)と同一視してください。 進められなかったFC Framesの数は使用されるアルゴリズムに基づいて異なるかもしれません。
b) return to forwarding FC Frames through the FC Frame Transmitter
Portal only after synchronization on the transmitted FCIP Frame
stream has been verified; and
b) 伝えられたFCIP Frameの流れの同期が確かめられた後にだけFC Frame Transmitter Portalを通して推進FC Framesに戻ってください。 そして
c) close the TCP/IP connection if the algorithm ends without
verifying successful synchronization. The probability of failing
to synchronize successfully and the time necessary to determine
whether or not synchronization was successful may vary with the
algorithm used.
c) アルゴリズムがうまくいっている同期について確かめないで終わるなら、TCP/IP接続を閉じてください。 アルゴリズムが使用されている状態で、首尾よく連動しないという確率と同期がうまくいったかどうか決定するのに必要な時間は異なるかもしれません。
An example algorithm meeting these requirements can be found in appendix D.
付録Dでこれらの必要条件を満たす例のアルゴリズムは見つけることができます。
The burden for recovering from the discarding of FCIP Frames during the optional resynchronization process described in this section falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
このセクションで説明された任意の再同期の過程の間、FCIP Framesを捨てるのから回復するための負担は、FC FabricのFC Entityと他の部品に落ちて、この仕様の範囲の外にあります。
Rajagopal, et al. Standards Track [Page 21] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[21ページ]。
6. Checking FC Frame Transit Times in the IP Network
6. IPネットワークでFCフレームトランジット回数をチェックします。
FC-BB-2 [3] defines how the measurement of IP Network transit time is performed, based on the requirements stated in the FC Frame Encapsulation [19] specification. The choice to place this implementation requirement on the FC Entity is based on a desire to include the transit time through the FCIP Entities when computing the IP Network transit time experienced by the FC Frames.
FC掲示板2[3]はIP Networkトランジット時間の測定がどう実行されるかを定義します、FC Frame Encapsulation[19]仕様に述べられた要件に基づいて。 この実現要件をFC Entityに置く選択はFC Framesによって経験されたIP Networkトランジット時間を計算するときFCIP Entitiesを通してトランジット時間を含む願望に基づいています。
Each FC Frame that enters the FCIP_DE through the FC Frame Receiver Portal SHALL be accompanied by a time stamp value that the FCIP_DE SHALL place in the Time Stamp [integer] and Time Stamp [fraction] fields of the encapsulation header of the FCIP Frame that contains the FC Frame. If no synchronized time stamp value is available to accompany the entering FC Frame, a value of zero SHALL be used.
それはFC Frame Receiver Portal SHALLを通してFCIP_DEに入ります。各FC Frame、FCIP_DE SHALLがTime Stamp[整数]に置くタイムスタンプ値とFC Frameを含むFCIP Frameのカプセル化ヘッダーのTime Stamp[断片]野原で、伴われてください。 どんな連動しているタイムスタンプ値も入っているFC Frame、SHALLがない値に伴うために利用可能でないなら、使用されてください。
Each FC Frame that exits the FCIP_DE through the FC Frame Transmitter Portal SHALL be accompanied by the time stamp value taken from the FCIP Frame that encapsulated the FC Frame.
各FC Frame、FC Frame Transmitter Portal SHALLを通した出口FCIP_DEはFC Frameを要約したFCIP Frameから取られたスタンプ値によって伴われます。
The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [26] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source, either Fibre Channel services or SNTP server.
FC Entity SHALLは、必要な連動している時間的価値を確立して、維持するのに適当な内部クロックとFibre ChannelサービスかSNTPバージョン4サーバ[26]のどちらかを利用します。 FC Entity SHALLは、それがFCIP LinkでコミュニケートしているFC Entityが同じ連動している時間ソース(Fibre ChannelサービスかSNTPサーバのどちらか)を使用していることを確かめます。
Note that since the FC Fabric is expected to have a single synchronized time value throughout, reliance on the Fibre Channel services means that only one synchronized time value is needed for all FCIP_DEs regardless of their connection characteristics.
ただ一つの連動している時間的価値を持っているFC Fabric以来予想される注意、Fibre Channelサービスへの信用は1つの連動している時間的価値だけが彼らの接続の特性にかかわらずすべてのFCIP_DEsに必要であることを意味します。
Rajagopal, et al. Standards Track [Page 22] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[22ページ]。
7. The FCIP Special Frame (FSF)
7. FCIPの特別なフレーム(FSF)
7.1. FCIP Special Frame Format
7.1. FCIPの特別なフレーム形式
Figure 9 shows the FSF format.
図9はFSF書式を示しています。
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 |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| | (0x00) | | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+-------------------------------+-------------------------------+
7| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
8| |
+----- Source FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| |
+----- Source FC/FCIP Entity Identifier -----+
11| |
+---------------------------------------------------------------+
12| |
+----- Connection Nonce -----+
13| |
+---------------+---------------+-------------------------------+
(Continued)
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| プロトコル#| バージョン| -プロトコル#| -バージョン| | (0×01) | (0×01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| プロトコル#| バージョン| -プロトコル#| -バージョン| | (0×01) | (0×01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags| 予約されます。| -pFlags| -予約されます。| | | (0×00) | | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| 旗| フレームの長さ| -旗| -フレームの長さ| | (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) | +-----------+-------------------+-----------+-------------------+ 4| タイムスタンプ[整数]| +---------------------------------------------------------------+ 5| タイムスタンプ[断片]| +---------------------------------------------------------------+ 6| CRC(FCIPでは、予約されます)| | (0×00 00-00-00) | +-------------------------------+-------------------------------+ 7| 予約されます。| -予約されます。| | (0×00-00) | (0xFF-ff) | +-------------------------------+-------------------------------+ 8| | +----- ソースのFCの骨組みの実体の世界的な名-----+ 9| | +---------------------------------------------------------------+ 10| | +----- ソースFC/FCIPエンティティ識別名-----+ 11| | +---------------------------------------------------------------+ 12| | +----- 接続一回だけ-----+ 13| | +---------------+---------------+-------------------------------+ (続けられています)
Figure 9: FSF Format (part 1 of 2)
図9: FSF形式(2の第1部)
Rajagopal, et al. Standards Track [Page 23] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[23ページ]。
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|
| |
| (Concluded) |
+---------------------------------------------------------------+
14| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
15| |
+----- Destination FC Fabric Entity World Wide Name -----+
16| |
+---------------------------------------------------------------+
17| K_A_TOV |
+-------------------------------+-------------------------------+
18| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
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| | | | (結論を下します) | +---------------------------------------------------------------+ 14| 接続| 予約されます。| 接続用法コード| | 用法旗| (0×00) | FC掲示板-2>で定義された<。| +---------------+---------------+-------------------------------+ 15| | +----- 目的地のFCの骨組みの実体の世界的な名-----+ 16| | +---------------------------------------------------------------+ 17| K_A_トゥブ| +-------------------------------+-------------------------------+ 18| 予約されます。| -予約されます。| | (0×00-00) | (0xFF-ff) | +-------------------------------+-------------------------------+
Figure 9: FSF Format (part 2 of 2)
図9: FSF形式(2の第2部)
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection, and only one FSF SHALL be transmitted in each direction.
FSF SHALL、最初のバイトが1FSF SHALLだけを各方向に伝えたので、伝えられたコネが各方向であったなら単に送ってください。
The contents of the FSF SHALL be as described for encapsulated FC Frames, except for the fields described in this section.
カプセル化されたFC Framesのために説明されるこのセクションで説明された分野を除いて、FSF SHALLの内容はそうです。
All FSFs SHALL have the pFlags SF bit set to 1 (see section 5.6.1).
すべてのFSFs SHALLがpFlags SFビットを1に設定させます(セクション5.6.1を見てください)。
The Source FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [4]. The Source FC Fabric Entity World Wide Name SHALL be world wide unique.
Source FC Fabric Entity World Wide Name分野SHALLはFSFを生成する(エコーと対照的に)FC/FCIP Entity組に関連しているFC Fabric実体のためのFibre Channel Name_Identifier[5]を含んでいます。 例えば、FC Fabric実体がFC Switchであるなら、FC Fabric Entity World Wide Name分野SHALLはSwitch_Name[4]を含んでいます。 世界中にいてください。Source FC Fabric Entity World Wide Name SHALL、ユニークです。
The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field.
Source FC/FCIP Entity Identifier分野SHALLはFSFを生成する(エコーと対照的に)FC/FCIP Entity組ユニークな識別子を含んでいます。 値は世界的な名前がSource FC Fabric Entity World Wide Name分野に現れるFC Fabric実体によって割り当てられます。
Note: The combination of the Source FC Entity World Wide Name and Source FC/FCIP Entity Identifier fields uniquely identifies every FC/FCIP Entity pair in the IP Network.
以下に注意してください。 Source FC Entity World Wide NameとSource FC/FCIP Entity Identifier分野の組み合わせはIP Networkで唯一すべてのFC/FCIP Entity組を特定します。
Rajagopal, et al. Standards Track [Page 24] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[24ページ]。
The Connection Nonce field shall contain a 64-bit random number generated to uniquely identify a single TCP connect request. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed.
Connection Nonce分野は唯一、TCPが接続するシングルを特定するために発生している乱数が要求する64ビットを含むものとします。 接続に、十分なセキュリティに一回だけ、Randomness Recommendationsを提供するには、Security[9]SHOULDに関して、続かれてください。
The Connection Usage Flags field identifies the types of SOF values [19] to be carried on the connection as shown in figure 10.
Connection Usage Flags分野は、10が中で計算するのが示されるように接続のときに運ばれるためにSOF値[19]のタイプを特定します。
|------------------------------Bit------------------------------| | | | 0 1 2 3 4 5 6 7 | +-------+-------+-------+-------+-------------------------------+ | SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved | +-------+-------+-------+-------+-------------------------------+
|------------------------------ビット------------------------------| | | | 0 1 2 3 4 5 6 7 | +-------+-------+-------+-------+-------------------------------+ | SOFf| SOF2?| SOF3?| SOF4?| 予約されます。| +-------+-------+-------+-------+-------------------------------+
Figure 10: Connection Usage Flags Field Format
図10: 接続用法はフィールド形式に旗を揚げさせます。
If the SOFf bit is one, then FC Frames containing SOFf are intended to be carried on the connection.
SOFfビットが1であるなら、接続のときにSOFfを含むFC Framesが運ばれることを意図します。
If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2 are intended to be carried on the connection.
2が噛み付いたSOFが1歳であるなら、接続のときにSOFi2とSOFn2を含むFC Framesが運ばれることを意図します。
If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3 are intended to be carried on the connection.
3が噛み付いたSOFが1歳であるなら、接続のときにSOFi3とSOFn3を含むFC Framesが運ばれることを意図します。
If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and SOFc4 are intended to be carried on the connection.
4が噛み付いたSOFが1歳であるなら、接続のときにSOFi4、SOFn4、およびSOFc4を含むFC Framesが運ばれることを意図します。
All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then the types of FC Frames intended to be carried on the connection have no specific relationship to the SOF code.
SOFf、SOF2?、SOF3?、およびSOFのすべてかいずれか--でない4ビットは1つに設定されるかもしれません。 SOF?優にSOFf、SOF2?、SOF3?、および4ビットがゼロであるなら、接続のときに運ばれることを意図するFC Framesのタイプには、SOFコードとのどんな特定の関係もありません。
The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below.
FCIP Entity SHALLはConnection Usage Flags分野によって説明されたSOF用法を実施しません、そして、SHALLは以下で説明されるように分野のコンテンツを使用するだけです。
The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [3].
定義されて、Connection Usage Code分野はFibre Channelを含んでいます。FC掲示板2[3]での指定されるとしての接続の意図している使用法の情報。
Rajagopal, et al. Standards Track [Page 25] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[25ページ]。
The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP Connection information (see section 8.1.1) and apply those settings to a newly formed connection.
FCIP Entity SHALLはTCP Connection情報の「共有された」データベースで適切なQoS設定の場所を見つけるのにConnection Usage FlagsとConnection Usage Code分野のコンテンツを使用して(セクション8.1.1を見ます)、新たに形成された接続にそれらの設定を適用します。
The Destination FC Fabric Entity World Wide Name field MAY contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that echoes (as opposed to generates) the Special Frame.
と対照的に、Destination FC Fabric Entity World Wide Name分野が反響するFC/FCIP Entity組に関連しているFC Fabric実体のためのFibre Channel Name_Identifier[5]を含むかもしれない、(生成する、)、Special Frame。
The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to be applied to the new TCP Connection as specified in FC-BB-2 [3].
K_A_TOV分野SHALLはFC掲示板2[3]の指定されるとしての新しいTCP Connectionに適用されるべきFC Keep Alive Timeout値を含んでいます。
For each new incoming TCP connect request and subsequent FSF received, the FCIP Entity SHALL send the contents of the Source FC Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other connection information (e.g., FCIP_LEP and FCIP_DE information).
それぞれの新しい入って来るTCPに関しては、要求を接続して、その後のFSFは受信しました、そして、FCIP Entity SHALLはもう片方の接続情報(例えば、FCIP_LEPとFCIP_DE情報)に伴うFC EntityにSource FC Fabric Entity World Wide Name、Source FC/FCIP Identifier、Connection Usage Flags、およびConnection Usage Code分野のコンテンツを送ります。
7.2. Overview of FSF Usage in Connection Establishment
7.2. コネクション確立におけるFSF用法の概要
When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions:
新しいTCP Connectionが設立されるとき、FCIP Special FrameはFCIP Entity開始からのTCPが操作を関連づける1つの周遊旅行をTCPを受けると接続するFCIP Entityにします。行き帰り、要求します。 このFSF用法は3つの機能を果たします:
- Identification of the FCIP Link endpoints
- FCIP Link終点の識別
- Conveyance of a few critical parameters shared by the FC/FCIP
Entity pairs involved in the FCIP Link
- FCIP LinkにかかわるFC/FCIP Entity組によって共有されたいくつかの臨界パラメータの運送
- Configuration discovery (used in place of SLP only when allowed by
site security policies)
- 構成発見(SLPに代わって、サイト安全保障政策で許容されている場合にだけ、使用されます)
The specific format and protocol requirements for this usage of the FSF are found in sections 7.1 and 8.1.2.3. This section provides an overview of the FSF usage without stating requirements.
FSFのこの使用法のための特定の形式とプロトコル要件はセクション7.1と8.1.2で.3に見つけられます。 要件を述べないで、このセクションはFSF用法の概要を提供します。
Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction.
FCIPがFibre Channel Fabricのためのトンネルであるにすぎなく、FabricにはFCIPリンクセットアップが必要とする多くに使うことができるそれ自身の複雑なリンクセットアップアルゴリズムがあるので、TCP Connectionセットアップの間、FSF用法の複雑さを最小にするのは望ましいです。 これが念頭にある状態で、このFSF用法は、ログインでない、またパラメタ交渉メカニズムではありません。 最初のバイトが各方向を送ったので、独身のFSFはそれぞれの新設されたTCP接続を通過します。
Rajagopal, et al. Standards Track [Page 26] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[26ページ]。
Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence.
以下に注意してください。 完全に接続のFC Fabric初期化が始まることができる前に新たに作成されたTCP Connectionが正しいFCIP Linkに関連しているに違いないので、FSFのこの使用法を排除できません。
The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 8.1 for specific algorithm requirements).
TCPから送られた最初のバイトは受信機への創始者が両方の送付者を特定するFSFであるという要求を接続します、そして、送付者がだれを考えるかは、受信機です。このFSFの内容が受信機に正しくて、許容できるなら、変わりのないFSFは送付者にecho backです。 これは発信します。/エコープロセスはTCP ConnectionがFC Fabricトラフィックを運ぶのに使用されるのを許容する唯一のセットの機能です。 発信してください。そうすれば、変わりのないエコープロセスは起こりません、とアルゴリズムがTCP Connectionの閉鎖におけるTCP Connection結果の1か両端で続きました(特定のアルゴリズム要件に関してセクション8.1を見てください)。
Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary.
以下に注意してください。 FSFが使用されている限られた方法とTCP Connectionが利用者データを運ぶことができる前にFSFが変化なしで反響されるという要件のために、TCPによって提供されたそれを超えてチェックしない誤りは全く必要であると考えられます。
As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 8.1.
上で説明されるように、TCP Connectionセットアップの間のFSF用法のプライマリ目的は新しいTCP Connectionが属するFCIP Linkを特定しています。 これらの始めから、それは簡易型の構成発見ツールとしてFSFを使用する思い描く小さい伸びにすぎません、そして、そのような用法の整備士はセクション8.1で説明されます。
However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLPv2 and most particularly lacks the security capabilities of SLPv2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 8.1.1.
しかしながら、FSFの構成発見の使用は、SLPv2によって提供された能力の広い声域を欠いていて、最も特にSLPv2のセキュリティ能力を欠いています。 これらの理由で、すべての環境には、構成発見にFSFを使用するのは適切ではありません。 したがって、発見目的にFSFを使用する選択は「共有された」データベースがセクション8.1.1で説明したTCP Connection特権階級の含まれるように特選している方針です。
When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows.
FSFベースの構成発見が可能にされるとき、上に概説された正常なTCP Connectionセットアップ規則は以下の通り変更されます。
Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up.
通常、FSFを受けるFCIP Entityによって実行されたアルゴリズムは、到着しているFSFのそれ自身の識別情報が正しいことを確かめて、それが閉じないならTCP Connectionを閉じるのを含んでいます。 あらかじめその要求(例えば、SLPを使用する)の目標であるFCIP Entityのアイデンティティを知るという要求を接続してください。そうすれば、事実上、言って、FSFを通して、「私は、X.と話していると思う」というTCPのもう一方の端のパーティーが接続するIfが本当にYであるよう要求するTCPを創始者に要求するとこれを見なすことができて、次に、それは単にハングアップします。
Rajagopal, et al. Standards Track [Page 27] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[27ページ]。
FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero.
FSFベースの発見はDestination FC Fabric Entity World Wide Name分野で明白な値をゼロに取り替えることによって達成される「私がだれと話しているか私に言ってくれますか?」に取り替えられるべきである「私は、Xと話していると思うこと」を許します。
If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator.
受信FCIP Entityの方針がFSFベースの発見を許すなら、ゼロを反響しているFSFの正しいDestination FC Fabric Entity World Wide Name値に取り替えます。 これはまだ変わりのないエコーと共に発信する規則を受けることがあるので、受け取られた反響しているFSFがTCPで創始者に接した後に、TCP Connectionの閉鎖は起こります。
Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful.
TCP Connection閉鎖にもかかわらず、しかしながら、TCPは創始者に接します。今、与えられたIP AddressのFCIP Entityの正しいDestination FC Fabric Entity World Wide Nameのアイデンティティは知っています、そして、その後のTCP Connectionセットアップ系列はたぶんうまくいくでしょう。
The Ch bit in the pFlags field (see section 5.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient.
pFlags分野(セクション5.6.1を見る)のChビットは、伝送エラーから生じながらFSFにおける変化の間で分化を考慮して、計画的行為から生じながら、FSF受取人で変化します。
8. TCP Connection Management
8. TCP接続管理
8.1. TCP Connection Establishment
8.1. TCPコネクション確立
8.1.1. Connection Establishment Model
8.1.1. コネクション確立モデル
The description of the connection establishment process is a model for the interactions between an FC Entity and an FCIP Entity during TCP Connection establishment. The model is written in terms of a "shared" database that the FCIP Entity consults to determine the properties of the TCP Connections to be formed combined with routine calls to the FC Entity when connections are successfully established. Whether the FC Entity contributes information to the "shared" database is not critical to this model. However, the fact that the FCIP Entity MAY consult the database at any time to determine its actions relative to TCP Connection establishment is important.
コネクション確立プロセスの記述はTCP Connection設立の間のFC EntityとFCIP Entityとの相互作用のためのモデルです。 モデルはFCIP Entityが接続が首尾よく確立されるとき、形成されるべきTCPコネクションズの特性がFC Entityへの通常の呼び出しに結合したことを決定するために相談すると「共有された」データベースで書かれています。 このモデルには、FC Entityが「共有された」データベースに情報を寄付するかどうかは、重要ではありません。 しかしながら、FCIP EntityがいつでもTCP Connection設立に比例して動作を決定するためにデータベースに相談するかもしれないという事実は重要です。
It is important to remember that this description is only a model for the interactions between an FC Entity and an FCIP Entity. Any implementation that has the same effects on the FC Fabric and IP Network as those described using the model meets the requirements of this specification. For example, an implementation might replace the "shared" database with a routine interface between the FC and FCIP Entities.
この記述がFC EntityとFCIP Entityとの相互作用のためのモデルにすぎないことを覚えているのは重要です。 ものが、モデルを使用すると説明したのでFC FabricとIP Networkへの同じ効果を持っているどんな実装もこの仕様に関する必要条件を満たします。 例えば、実装は「共有された」データベースをFCとFCIP Entitiesとの通常のインタフェースに取り替えるかもしれません。
Rajagopal, et al. Standards Track [Page 28] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[28ページ]。
8.1.2. Creating New TCP Connections
8.1.2. 新しいTCPコネクションズを作成します。
8.1.2.1. Non-Dynamic Creation of New TCP Connections
8.1.2.1. 新しいTCPコネクションズの非ダイナミックな作成
When an FCIP Entity discovers that a new TCP Connection needs to be established, it SHALL determine the IP Address to which the TCP Connection is to be made and establish all enabled IP security features for that IP Address as described in section 9. Then the FCIP Entity SHALL determine the following information about the new connection in addition to the IP Address:
FCIP Entityがそれを発見するとき、新しいTCP Connectionは、設立される必要があります、それ。SHALLはTCP ConnectionがされることになっているIP Addressを決定して、セクション9で説明されるようにそのIP Addressのためのすべて可能にされたIPセキュリティ機能を確立します。 次に、FCIP Entity SHALLはIP Addressに加えて新しい接続の以下の情報を決定します:
- The expected Destination FC Fabric Entity World Wide Name of the
FC/FCIP Entity pair to which the TCP Connection is being made
- TCP Connectionが作られているFC/FCIP Entity組の予想されたDestination FC Fabric Entity World Wide Name
- TCP Connection Parameters (see section 8.3)
- TCP接続パラメタ(セクション8.3を見ます)
- Quality of Service Information (see section 10)
- サービスの質情報(セクション10を見ます)
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the specified IP Address.
この情報に基づいて、FCIP Entity SHALLは指定されたIP Addressで3225年(他の構成の特定のポートナンバー)のFCIP Wellによって知られているPortへの要求[6]をTCPが接続するaに生成します。
If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. For example, the FCIP Entity might wait 60 seconds before trying to re-establish the connection.
TCPが接続するなら、要求は拒絶されます、同様の接続を確立する試みの不要な反復を制限するFCIP Entity SHALL条例。 例えば、接続を復職させようとする前に、FCIP Entityは60秒待つかもしれません。
If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
TCPが接続するなら、要求を受け入れます、とFCIP Entity SHALLは続きます。ステップはセクション8.1.2で新しいFCIP_DEの設立を終了する.3について説明しました。
It is RECOMMENDED that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
どんな開始TCPも接続しないFCIP Entityが、入って来るTCPがそのFCIP Entityからの要求を接続するならFCIP Entityが既に受け入れられたよう別のものに要求するのは、RECOMMENDEDです。
8.1.2.2. Dynamic Creation of New TCP Connections
8.1.2.2. 新しいTCPコネクションズのダイナミックな作成
If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17] in the manner defined for FCIP usage [20].
FCIP Entitiesは参加するダイナミックな発見であるならサポートされます、機能SHALL。FCIP用法[20]のために定義された方法でService Locationプロトコル(SLPv2)[17]を使用することで、実行されてください。
Upon discovering that dynamic discovery is to be used, the FCIP Entity SHALL enable IP security features for the SLP discovery process as described in [20] and then:
ダイナミックな発見が使用されていることであると発見すると、FCIP Entity SHALLは[20]とその時説明されるようにSLP発見プロセスのためのIPセキュリティ機能を可能にします:
1) Determine the one or more FCIP Discovery Domain(s) to be used in
the dynamic discovery process;
1) 1FCIPディスカバリーDomain(s)がダイナミックな発見プロセスで使用されることを決定してください。
Rajagopal, et al. Standards Track [Page 29] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[29ページ]。
2) Establish an SLPv2 Service Agent to advertise the availability of
this FCIP Entity to peer FCIP Entities in the identified FCIP
Discovery Domain(s); and
2) SLPv2 Serviceエージェントを設立して、特定されたFCIPディスカバリーDomain(s)の同輩FCIP EntitiesにこのFCIP Entityの有用性の広告を出してください。 そして
3) Establish an SLPv2 User Agent to locate service advertisements for
peer FCIP Entities in the identified FCIP Discovery Domain(s).
3) SLPv2 Userエージェントを設立して、特定されたFCIPディスカバリーDomain(s)で同輩FCIP Entitiesのためのサービス広告の場所を見つけてください。
For each peer FCIP Entity dynamically discovered through the SLPv2 User Agent, the FCIP Entity SHALL establish all enabled IP security features for the discovered IP Address as described in section 9 and then determine the following information about the new connection:
SLPv2 Userエージェントを通してダイナミックに発見されたそれぞれの同輩FCIP Entityに関しては、FCIP Entity SHALLは発見されたIP Addressのためにセクション9で説明されるようにすべての可能にされたIPセキュリティ機能を確立して、次に、新しい接続に関して以下の情報を決定します:
- The expected Destination FC Fabric Entity World Wide Name of the
FC/FCIP Entity pair to which the TCP Connection is being made
- TCP Connectionが作られているFC/FCIP Entity組の予想されたDestination FC Fabric Entity World Wide Name
- TCP Connection Parameters (see section 8.3)
- TCP接続パラメタ(セクション8.3を見ます)
- Quality of Service Information (see section 10)
- サービスの質情報(セクション10を見ます)
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the IP Address specified by the service advertisement. If the TCP connect request is rejected, act to limit unnecessary repetition of attempts to establish similar connections. If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
この情報に基づいて、FCIP Entity SHALLはサービス広告で指定されたIP Addressで3225年(他の構成の特定のポートナンバー)のFCIP Wellによって知られているPortへの要求[6]をTCPが接続するaに生成します。 TCPが接続するなら、要求は拒絶されて、不要な反復を制限する行為は、同様の接続を確立するのを試みます。 TCPが接続するなら、要求を受け入れます、とFCIP Entity SHALLは続きます。ステップはセクション8.1.2で新しいFCIP_DEの設立を終了する.3について説明しました。
It is recommended that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
どんな開始TCPも接続しないFCIP Entityが、入って来るTCPがそのFCIP Entityからの要求を接続するならFCIP Entityが既に受け入れられたよう別のものに要求するのは、お勧めです。
8.1.2.3. Connection Setup After a Successful TCP Connect Request
8.1.2.3. うまくいっているTCPが要求を接続した後に接続設定
Whether Non-Dynamic TCP Connection creation (see section 8.1.2.1) or Dynamic TCP Connection creation (see section 8.1.2.2) is used, the steps described in this section SHALL be followed to take the TCP Connection setup process to completion.
.2が)使用されて、ステップはこのセクションでSHALLについて説明しました。NonダイナミックなTCP Connection作成、(セクション8.1.2の.1か)Dynamic TCP Connection作成を見てください、(セクション8.1.2を見てください、完成にTCP Connectionセットアッププロセスで取るには、続かれてください。
After the TCP connect request has been accepted, the FCIP Entity SHALL send an FCIP Special Frame (FSF, see section 7) as the first bytes transmitted on the newly formed connection, and retain a copy of those bytes for later comparisons. All fields in the FSF SHALL be filled in as described in section 7, particularly:
TCPが接続した後に、要求を受け入れて、FCIP Entity SHALLは最初のバイトが新たに形成された接続のときに伝わったようにFCIP Special Frame(FSF、セクション7を見る)を送って、後の比較のためのそれらのバイトのコピーを保有します。 セクション7で説明されるように中にいっぱいにされて、すべてが中で特にFSF SHALLをさばきます:
- The Source FC Fabric Entity World Wide Name field SHALL contain
the FC Fabric Entity World Wide Name for the FC/FCIP Entity pair
that is originating the TCP connect request;
- Source FC Fabric Entity World Wide Name分野SHALLはFC/FCIP Entity組FC Fabric Entity World Wide Nameを含んでいます、すなわち、起因して、TCPは要求を接続します、。
Rajagopal, et al. Standards Track [Page 30] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[30ページ]。
- The Source FC/FCIP Entity Identifier field SHALL contain a unique
identifier that is assigned by the FC Fabric entity whose world
wide name appears in the Source FC Fabric Entity World Wide Name
field;
- Source FC/FCIP Entity Identifier分野SHALLは世界的な名前がSource FC Fabric Entity World Wide Name分野に現れるFC Fabric実体によって割り当てられるユニークな識別子を含んでいます。
- The Connection Nonce field SHALL contain a 64-bit random number
that differs in value from any recently used Connection Nonce
value. In order to provide sufficient security for the connection
nonce, the Randomness Recommendations for Security [9] SHOULD be
followed; and
- Connection Nonce分野SHALLはどんな最近中古のConnection Nonce値とも値において異なる64ビットの乱数を含んでいます。 接続に、十分なセキュリティに一回だけ、Randomness Recommendationsを提供するには、Security[9]SHOULDに関して、続かれてください。 そして
- The Destination FC Fabric Entity World Wide Name field SHALL
contain 0 or the expected FC Fabric Entity World Wide Name for the
FC/FCIP Entity pair whose destination is the TCP connect request.
- Destination FC Fabric Entity World Wide Name分野SHALLが0を含んでいるか、または目的地がTCPであるFC/FCIP Entity組予想されたFC Fabric Entity World Wide Nameは要求を接続します。
After the FSF is sent on the newly formed connection, the FCIP Entity SHALL wait for the FSF to be echoed as the first bytes received on the newly formed connection.
新たに形成された接続にFSFを送った後に、FCIP Entity SHALLは、FSFが新たに形成された接続のときに受け取られた最初のバイトとして反響されるのを待っています。
The FCIP Entity MAY apply a timeout of not less than 90 seconds while waiting for the echoed FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
FCIP Entityは反響しているFSFバイトを待っている間、少なくとも90秒のタイムアウトを適用するかもしれません。 タイムアウトが期限が切れるなら、FCIP Entity SHALLは閉鎖の理由でTCP Connectionを閉じて、FC Entityに通知します。
If the echoed FSF bytes do not exactly match the FSF bytes sent (words 7 through 17 inclusive) or if the echoed Destination FC Fabric Entity World Wide Name field contains zero, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
反響しているFSFバイトがまさにバイトが送った(包括的に7〜17を言い表します)FSFに合っていないか、または反響しているDestination FC Fabric Entity World Wide Name分野がゼロを含んでいるなら、FCIP Entity SHALLは閉鎖の理由でTCP Connectionを閉じて、FC Entityに通知します。
The FCIP Entity SHALL only perform the following steps if the echoed FSF bytes exactly match the FSF bytes sent (words 7 through 17 inclusive).
反響しているFSFバイトがまさにバイトが送った(包括的に7〜17を言い表します)FSFに合っている場合にだけ、FCIP Entity SHALLは以下のステップを実行します。
1) Instantiate the appropriate Quality of Service (see section 10)
conditions on the newly created TCP Connection,
1) 新たに作成されたTCP Connectionに関するService(セクション10を見る)状態の適切なQualityを例示してください。
2) If the IP Address and TCP Port to which the TCP Connection was
made is not associated with any other FCIP_LEP, create a new
FCIP_LEP for the new FCIP Link,
2) TCP ConnectionがされたIP AddressとTCP Portがいかなる他のFCIP_LEPにも関連づけられないなら、新しいFCIP Linkのために新しいFCIP_LEPを作成してください。
3) Create a new FCIP_DE within the newly created FCIP_LEP to service
the new TCP Connection, and
3) そして新たに作成されたFCIP_LEPの中で新しいFCIP_DEを作成して、新しいTCP Connectionを調整してください。
4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination FC
Fabric Entity World Wide Name, Connection Usage Flags, and
Connection Usage Code.
4) 新しいFCIP_LEP、FCIP_DE、Destination FC Fabric Entity World Wide Name、Connection Usage Flags、およびConnection Usage CodeについてFC Entityに知らせてください。
Rajagopal, et al. Standards Track [Page 31] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[31ページ]。
8.1.3. Processing Incoming TCP Connect Requests
8.1.3. 処理の入って来るTCPは要求を接続します。
The FCIP Entity SHALL listen for new TCP Connection requests [6] on the FCIP Well-Known Port (3225). An FCIP Entity MAY also accept and establish TCP Connections to a TCP port number other than the FCIP Well-Known Port, as configured by the network administrator in a manner outside the scope of this specification.
FCIP Entity SHALLはFCIP Wellによって知られているPort(3225)で新しいTCP Connection要求[6]の聞こうとします。 また、FCIP EntityはFCIP Wellによって知られているPort以外のTCPポートナンバーにTCPコネクションズを受け入れて、確立するかもしれません、この仕様の範囲の外の方法でネットワーク管理者によって構成されるように。
The FCIP Entity SHALL determine the following information about the requested connection:
FCIP Entity SHALLは要求された接続の以下の情報を決定します:
- Whether the "shared" database (see section 8.1.1) allows the
requested connection
- 「共有された」データベース(セクション8.1.1を見る)が要求された接続を許して
- Whether IP security setup has been performed for the IP security
features enabled on the connection (see section 9)
- IPセキュリティセットアップが接続のときに可能にされたIPセキュリティ機能のために実行されて(セクション9を見ます)
If the requested connection is not allowed, the FCIP Entity SHALL reject the connect request using appropriate TCP means. If the requested connection is allowed, the FC Entity SHALL ensure that required IP security features are enabled and accept the TCP connect request.
要求された接続が許されていなくて、FCIP Entity SHALLが廃棄物である、適切なTCPが意味する要求使用を接続してください。 要求された接続が許されているなら、FC Entity SHALLは必要であることで、IPセキュリティ機能が可能にされるのを確実にして、受け入れます。TCPは要求を接続します。
After the TCP connect request has been accepted, the FCIP Entity SHALL wait for the FSF sent by the originator of the TCP connect request (see section 8.1.2) as the first bytes received on the accepted connection.
TCPが接続した後に、要求を受け入れて、TCPの創始者によって送られたFSFが最初のバイトとして要求(セクション8.1.2を見る)を接続するので、FCIP Entity SHALL待ちは受け入れられた接続のときに受信されました。
The FCIP Entity MAY apply a timeout of no less than 90 seconds while waiting for the FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
FCIP EntityはFSFバイトを待っている間、少なくとも90秒のタイムアウトを適用するかもしれません。 タイムアウトが期限が切れるなら、FCIP Entity SHALLは閉鎖の理由でTCP Connectionを閉じて、FC Entityに通知します。
Note: One method for attacking the security of the FCIP Link formation process (detailed in section 9.1) depends on keeping a TCP connect request open without sending an FSF. Implementations should bear this in mind in the handling of TCP connect requests where the FSF is not sent in a timely manner.
以下に注意してください。 FSFを送らないで、FCIP Link構成プロセス(セクション9.1で詳細な)のセキュリティを攻撃するのがTCPを保つのによるので、1つのメソッドが要求戸外をつなげます。 実装はこれほど念頭にTCPの取り扱いが接続するコネとしてFSFが直ちに送られない要求を持つべきです。
Upon receipt of the FSF sent by the originator of the TCP connect request, the FCIP Entity SHALL inspect the contents of the following fields:
TCPの創始者によって送られたFSFを受け取り次第、要求を接続してください、そして、FCIP Entity SHALLは以下の分野のコンテンツを点検します:
- Connection Nonce, - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code.
- そして、接続一回だけ--目的地のFCの骨組みの実体の世界的な名--接続用法が弛む、--接続用法コード。
Rajagopal, et al. Standards Track [Page 32] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[32ページ]。
If the Connection Nonce field contains a value identical to the most recently received Connection Nonce from the same IP Address, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
Connection Nonce分野が同じIP Addressからの最も最近容認されたConnection Nonceと同じ値を含んでいるなら、FCIP Entity SHALLは閉鎖の理由でTCP Connectionを閉じて、FC Entityに通知します。
If an FCIP Entity receives a duplicate FSF during the FCIP Link formation process, it SHALL close that TCP Connection and notify the FC Entity with the reason for the closure.
FCIP EntityがFCIP Linkの間、写しFSFを受けるなら、構成は処理されます、それ。SHALLは閉鎖の理由でそのTCP Connectionを閉じて、FC Entityに通知します。
If the Destination FC Fabric Entity World Wide Name contains 0, the FCIP Entity SHALL take one of the following three actions:
Destination FC Fabric Entity World Wide Nameが0を含んでいるなら、FCIP Entity SHALLは以下の3つの動作の1つを取ります:
1) Leave the Destination FC Fabric Entity World Wide Name field and
Ch bit both 0;
1) Destination FC Fabric Entity World Wide Name野原とChビットをともに0に出てください。
2) Change the Destination FC Fabric Entity World Wide Name field to
match FC Fabric Entity World Wide Name associated with the FCIP
Entity that received the TCP connect request and change the Ch bit
to 1; or
2) Destination FC Fabric Entity World Wide NameがTCPを受けたFCIP Entityに関連しているFC Fabric Entity World Wide Nameを合わせるためにさばく変化は、1に要求を関連づけて、Chビットを変えます。 または
3) Close the TCP Connection without sending any response.
3) どんな応答も送らないで、TCP Connectionを閉じてください。
The choice between the above actions depends on the anticipated usage of the FCIP Entity. The FCIP Entity may consult the "shared" database when choosing between the above actions.
上の動作のこの選択はFCIP Entityの予期された使用法次第です。 上の動作を選ぶとき、FCIP Entityは「共有された」データベースに相談するかもしれません。
If:
a) The Destination FC Fabric Entity World Wide Name contains a non-
zero value that does not match the FC Fabric Entity World Wide
Name associated with the FCIP Entity that received the TCP connect
request, or
: a) Destination FC Fabric Entity World Wide Nameは非ゼロを含んでいます。またはTCPを受けたFCIP Entityに関連しているFC Fabric Entity World Wide Nameに合っていない値が要求を接続する。
b) The contents of the Connection Usage Flags and Connection Usage
Code fields is not acceptable to the FCIP Entity that received the
TCP connect request, then the FCIP Entity SHALL take one of the
following two actions:
b) Connection Usage FlagsとConnection Usage Code分野のコンテンツはFCIP Entityに許容できません。次に、受け取って、TCPが接続するのがFCIP Entity SHALLが以下の2つの動作の1つを取るよう要求します:
1) Change the contents of the unacceptable fields to correct/
acceptable values and set the Ch bit to 1; or
1) 容認できない分野のコンテンツを正しいか許容できる値に変えてください、そして、Chビットを1に設定してください。 または
2) Close the TCP Connection without sending any response.
2) どんな応答も送らないで、TCP Connectionを閉じてください。
If the FCIP Entity makes any changes in the content of the FSF, it SHALL also set the Ch bit to 1.
いずれかFCIP Entity造であるならFSFの内容で変化します、それ。また、SHALLはChビットを1に設定します。
If any changes have been made in the received FSF during the processing described above, the following steps SHALL be performed:
変更はいずれかであるなら上で説明された処理の間、容認されたFSFで行われていて、以下のステップはSHALLです。実行されてください:
Rajagopal, et al. Standards Track [Page 33] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[33ページ]。
1) The changed FSF SHALL be echoed to the originator of the TCP
connect request as the only bytes transmitted on the accepted
connection;
1) 創始者に反響されてください。変えられたFSF SHALL、TCPでは、受け入れられた接続のときに伝えられた唯一のバイトとして要求を接続してください。
2) The TCP Connection SHALL be closed (the FC Entity need not be
notified of the TCP Connection closure in this case because it is
not indicative of an error); and
2) TCP Connection SHALL、閉じられてください(それが誤りを暗示していないので、FC Entityはこの場合TCP Connection閉鎖について通知される必要はありません)。 そして
3) All of the additional processing described in this section SHALL
be skipped.
3) 追加処理のすべてがこのセクションでSHALLについて説明しました。スキップされます。
The remaining steps in this section SHALL be performed only if the FCIP Entity has not changed the contents of the above mentioned fields to correct/acceptable values.
残りはこのセクションでSHALLを踏みます。FCIP Entityが/許容値を修正するために上記の分野のコンテンツを変えていない場合にだけ、実行されてください。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FSF do not match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with any other FCIP_LEP, the FCIP Entity SHALL:
FSFのSource FC Fabric Entity World Wide NameとSource FC/FCIP Entity Identifier分野値が合っていないなら、Source FC Fabric Entity World Wide NameとSource FC/FCIP Entity Identifierはいかなる他のFCIP_LEPとも交際しました、FCIP Entity SHALL:
1) Echo the unchanged FSF to the originator of the TCP connect
request as the first bytes transmitted on the accepted connection;
1) TCPの創始者への変わりのないFSFが接続するエコーは、1番目としてバイトが受け入れられた接続のときに伝わったよう要求します。
2) Instantiate the appropriate Quality of Service (see section 10.2)
conditions on the newly created TCP Connection, considering the
Connection Usage Flags and Connection Usage Code fields, and
"shared" database information (see section 8.1.1) as appropriate,
2) 新たに作成されたTCP Connectionに関するService(セクション10.2を見る)状態の適切なQualityを例示してください、適宜、Connection Usage Flags、Connection Usage Code分野、および「共有された」データベース情報(セクション8.1.1を見る)を考える場合
3) Create a new FCIP_LEP for the new FCIP Link,
3) 新しいFCIP Linkのために新しいFCIP_LEPを作成してください。
4) Create a new FCIP_DE within the newly created FCIP_LEP to service
the new TCP Connection, and
4) そして新たに作成されたFCIP_LEPの中で新しいFCIP_DEを作成して、新しいTCP Connectionを調整してください。
5) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC
Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier,
Connection Usage Flags, and Connection Usage Code.
5) 新しいFCIP_LEP、FCIP_DE、Source FC Fabric Entity World Wide Name、Source FC/FCIP Entity Identifier、Connection Usage Flags、およびConnection Usage CodeについてFC Entityに知らせてください。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Special Frame match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with an existing FCIP_LEP, the FCIP Entity SHALL:
FCIP Special FrameのSource FC Fabric Entity World Wide NameとSource FC/FCIP Entity Identifier分野値が合っているなら、Source FC Fabric Entity World Wide NameとSource FC/FCIP Entity Identifierは既存のFCIP_LEPと交際しました、FCIP Entity SHALL:
1) Request that the FC Entity authenticate the source of the TCP
connect request (see FC-BB-2 [3]), providing the following
information to the FC Entity for authentication purposes:
1) FC EntityがTCPの源を認証するという要求は要求を接続します。(FC掲示板2[3])を見てください、認証目的のために以下の情報をFC Entityに供給して:
Rajagopal, et al. Standards Track [Page 34] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[34ページ]。
a) Source FC Fabric Entity World Wide Name,
b) Source FC/FCIP Entity Identifier, and
c) Connection Nonce.
a) ソースFC Fabric Entity World Wide Name、b) ソースFC/FCIP Entity Identifier、およびc) 接続一回だけ。
The FCIP Entity SHALL NOT use the new TCP Connection for any
purpose until the FC Entity authenticates the source of the TCP
connect request. If the FC Entity indicates that the TCP connect
request cannot be properly authenticated, the FCIP Entity SHALL
close the TCP Connection and skip all of the remaining steps in
this section.
どんなFC Entityまでの目的のための新しいTCP Connectionもソースを認証する使用ではなく、FCIP Entity SHALL TCPは要求を接続します。 FC Entityが、TCPが接続するのを示すなら適切に要求を認証できないで、FCIP Entity SHALLはこのセクションでTCP Connectionを閉じて、残っているステップのすべてをスキップします。
The definition of the FC Entity SHALL include an authentication
mechanism for use in response to a TCP connect request source that
communicates with the partner FC/FCIP Entity pair on an existing
FCIP Link. This authentication mechanism should use a previously
authenticated TCP Connection in the existing FCIP Link to
authenticate the Connection Nonce sent in the new TCP Connection
setup process. The FCIP Entity SHALL treat failure of this
authentication as an authentication failure for the new TCP
Connection setup process.
TCPに対応した使用が既存のFCIP LinkでパートナーFC/FCIP Entity組とコミュニケートする要求情報筋に接するので、FC Entity SHALLの定義は認証機構を含んでいます。 この認証機構は、新しいTCP Connectionセットアッププロセスで送られたConnection Nonceを認証するのに既存のFCIP Linkで以前に認証されたTCP Connectionを使用するはずです。 FCIP Entity SHALLは新しいTCP Connectionセットアッププロセスのためにこの認証の失敗を認証失敗として扱います。
2) Echo the unchanged FSF to the originator of the TCP connect
request as the first bytes transmitted on the accepted connection;
2) TCPの創始者への変わりのないFSFが接続するエコーは、1番目としてバイトが受け入れられた接続のときに伝わったよう要求します。
3) Instantiate the appropriate Quality of Service (see section 10.2)
conditions on the newly created TCP Connection, considering the
Connection Usage Flags and Connection Usage Code fields, and
"shared" database information (see section 8.1.1) as appropriate,
3) 新たに作成されたTCP Connectionに関するService(セクション10.2を見る)状態の適切なQualityを例示してください、適宜、Connection Usage Flags、Connection Usage Code分野、および「共有された」データベース情報(セクション8.1.1を見る)を考える場合
4) Create a new FCIP_DE within the existing FCIP_LEP to service the
new TCP Connection, and
4) そして既存のFCIP_LEPの中で新しいFCIP_DEを作成して、新しいTCP Connectionを調整してください。
5) Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity
World Wide Name, Source FC/FCIP Entity Identifier, Connection
Usage Flags, Connection Usage Code, and new FCIP_DE.
5) FCIP_LEP、Source FC Fabric Entity World Wide Name、Source FC/FCIP Entity Identifier、Connection Usage Flags、Connection Usage Code、および新しいFCIP_DEについてFC Entityに知らせてください。
Note that the originator of TCP connect requests uses the IP Address and TCP Port to identify which TCP Connections belong to which FCIP_LEPs while the recipient of TCP connect requests uses the Source FC Fabric Entity World Wide Name, and Source FC/FCIP Entity Identifier fields from the FSF to identify which TCP Connection belong to which FCIP_LEPs. For this reason, an FCIP Entity that both originates and receives TCP connect requests is unable to match the FCIP_LEPs associated with originated TCP connect requests to the FCIP_LEPs associated with received TCP connect requests.
TCPの創始者がどのTCPコネクションズが属するかを特定するために要求の用途のIP AddressとTCP Portを接続するというFCIP_LEPsがTCPの受取人である間に要求を関連づけるメモはSource FC Fabric Entity World Wide Nameを使用します、そして、どのTCP Connectionを特定するかFSFからのSource FC/FCIP Entity Identifier分野はどのFCIP_LEPsに属すか。 要求は溯源されたTCPに関連しているLEPsが_LEPsが関連づけたFCIPへの要求を接続するFCIP_に合うことができません。この理由、ともにTCPを溯源して、受けるFCIP Entityに関して接続してください、受け取って、TCPは要求を接続します。
Rajagopal, et al. Standards Track [Page 35] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[35ページ]。
8.1.4. Simultaneous Connection Establishment
8.1.4. 同時接続設立
If two FCIP Entities perform simultaneous open operations, then two TCP Connections are formed and the SF originates at one end on one connection and at the other end on the other. Connection setup proceeds as described above on both connections, and the steps described above properly result in the formation of two FCIP Links between the same FCIP Entities.
2FCIP Entitiesが同時の開放的手術を実行するなら、2つのTCPコネクションズが形成されます、そして、SFは1つの接続での片端においてもう片方のもう一方の端ときの起因します。 接続設定は両方の接続のときに上で説明されるように続きます、そして、上で適切に説明されたステップは同じFCIP Entitiesの間で2FCIPリンクスの構成をもたらします。
This is not an error. Fibre Channel is perfectly capable of handling two approximately equal connections between FC Fabric elements.
これは誤りではありません。 繊維ChannelはFC Fabric要素の間の2つのほとんど等しい接続を完全に扱うことができます。
The decision to setup pairs of FCIP Links in this manner is considered to be a site policy decision that can be covered in the "shared" database described in section 8.1.1.
FCIPリンクスの組をセットアップするという決定はセクション8.1.1で説明された「共有された」データベースでカバーできるサイト政策決定であるとこの様に考えられます。
8.2. Closing TCP Connections
8.2. TCPコネクションズを閉じます。
The FCIP Entity SHALL provide a mechanism with acknowledgement by which the FC Entity is able to cause the closing of an existing TCP Connection at any time. This allows the FC Entity to close TCP Connections that are producing too many errors, etc.
FCIP Entity SHALLはFC Entityがいつでも既存のTCP Connectionの閉鎖を引き起こすことができる承認をメカニズムに提供します。 これで、FC Entityはあまりに多くの誤りなどを生産しているTCPコネクションズを閉じることができます。
8.3. TCP Connection Parameters
8.3. TCP接続パラメタ
In order to provide efficient management of FCIP_LEP resources as well as FCIP Link resources, consideration of certain TCP Connection parameters is recommended.
FCIP Linkリソースと同様にFCIP_LEPリソースの能率的経営を提供するために、あるTCP Connectionパラメタの考慮はお勧めです。
8.3.1. TCP Selective Acknowledgement Option
8.3.1. TCPの選択している承認オプション
The Selective Acknowledgement option RFC 2883 [18] allows the receiver to acknowledge multiple lost packets in a single ACK, enabling faster recovery. An FCIP Entity MAY negotiate use of TCP SACK and use it for faster recovery from lost packets and holes in TCP sequence number space.
Selective AcknowledgementオプションRFC2883[18]は独身のACKの複数の無くなっているパケットを承認するために受信機を許容します、より速い回復を可能にして。 FCIP EntityはTCP一連番号スペースの無くなっているパケットと穴からの、より速い回復にTCP SACKの使用を交渉して、それを使用するかもしれません。
8.3.2. TCP Window Scale Option
8.3.2. TCP窓のスケールオプション
The TCP Window Scale option [8] allows TCP window sizes larger than 16-bit limits to be advertised by the receiver. It is necessary to allow data in long fat networks to fill the available pipe. This also implies buffering on the TCP sender that matches the (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses locally available mechanisms to set a window size that matches the available local buffer resources and the desired throughput.
TCP Window Scaleオプション[8]は、16ビットの限界より大きいTCPウィンドウサイズが受信機で広告を出すのを許容します。長い太っているネットワークにおけるデータが利用可能なパイプをいっぱいにするのを許容するのが必要です。 また、これは、TCP送付者の上でそれをバッファリングするとTCP Connectionの(帯域幅*遅れ)製品が合っているのを含意します。 FCIP_LEPは、利用可能なローカルのバッファ資源と必要なスループットに合っているウィンドウサイズを設定するのに局所的に利用可能なメカニズムを使用します。
Rajagopal, et al. Standards Track [Page 36] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[36ページ]。
8.3.3. Protection Against Sequence Number Wrap
8.3.3. 一連番号包装に対する保護
It is RECOMMENDED that FCIP Entities implement protection against wrapped sequence numbers PAWS [8]. It is quite possible that within a single connection, TCP sequence numbers wrap within a timeout window.
FCIP Entitiesが包装された一連番号PAWS[8]に対する保護を実装するのは、RECOMMENDEDです。 単独結合の中では、TCP一連番号がタイムアウトの窓を中に包装するのは、かなり可能です。
8.3.4. TCP_NODELAY Option
8.3.4. TCP_NODELAYオプション
FCIP Entities should disable the Nagle Algorithm as described in RFC 1122 [7] section 4.2.3.4. By tradition, this can be accomplished by setting the TCP_NODELAY option to one at the local TCP interface.
FCIP EntitiesはRFC1122[7]セクション4.2.3.4で説明されるようにネーグルAlgorithmを無効にするはずです。 伝統で、地方のTCPインタフェースの1つにTCP_NODELAYオプションを設定することによって、これを達成できます。
8.4. TCP Connection Considerations
8.4. TCP接続問題
In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [3]).
無駄なモードで、通常、「生きているままでいてください」というTCPのTCP Connectionオプションは、接続を生かすのに使用されます。 しかしながら、このタイムアウトは、かなり大きく、接続性の損失の早期発見を防ぐかもしれません。 FC Entities SHOULDは、接続性の損失の、より速い検出を容易にするために何らかの形式のFibre Channel接続が失敗検出であると実装します。(FC掲示板2[3])を考えてください。
When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure.
FCIP Entityが、TCPの接続性が失われたと発見するとき、失敗が失敗の理由の情報を含むのについてFCIP Entity SHALLはFC Entityに通知します。
8.5. Flow Control Mapping between TCP and FC
8.5. TCPとFCの間のフロー制御マッピング
The FCIP Entity and FC Entity are connected to the IP Network and FC Fabric, respectively, and they need to follow the flow control mechanisms of both TCP and FC, which work independently of each other.
FCIP EntityとFC EntityはそれぞれIP NetworkとFC Fabricに接続されます、そして、彼らは互いの如何にかかわらず働いているTCPとFCの両方のフロー制御メカニズムに従う必要があります。
This section provides guidelines as to how the FCIP Entity can map TCP flow control to status notifications to the FC Entity.
FCIP EntityがどうFC Entityへの状態通知にTCPフロー制御を写像できるかに関してこのセクションはガイドラインを提供します。
There are two scenarios in which the flow control management becomes crucial:
フロー制御管理が重要になる2つのシナリオがあります:
1) When there is line speed mismatch between the FC and IP
interfaces.
1) ライン・スピードがあるときには、FCとIPの間でインタフェースにミスマッチしてください。
Even though it is RECOMMENDED that both of the FC and IP
interfaces to the FC Entity and FCIP Entity, respectively, be of
comparable speeds, it is possible to carry FC traffic over an IP
Network that has a different line speed and bit error rate.
FC EntityとFCIP EntityへのFCとIPインタフェースの両方がそれぞれ匹敵する速度のそうであることがRECOMMENDEDですが、異なったライン・スピードとビット誤り率を持っているIP Networkの上までFCトラフィックを運ぶのは可能です。
Rajagopal, et al. Standards Track [Page 37] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[37ページ]。
2) When the FC Fabric or IP Network encounters congestion.
2) FC FabricかIP Networkが混雑に遭遇すると。
Even when both the FC Fabric or IP network are of comparable
speeds, during the course of operation, the FC Fabric or the IP
Network could encounter congestion due to transient conditions.
FC FabricかIPネットワークの両方が操作のコース、FC FabricまたはIP Networkの間の匹敵する速度のいつかが一時的な状態による混雑に遭遇さえできました。
The FC Entity uses Fibre Channel mechanisms for flow control at the FC Frame Receiver Portal based on information supplied by the FCIP Entity regarding flow constraints at the Encapsulated Frame Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow control at the Encapsulated Frame Receiver Portal based on information supplied by the FC Entity regarding flow constraints at the FC Frame Transmitter Portal.
FC Entityはフロー制御にEncapsulated Frame Transmitter Portalで流れ規制に関してFCIP Entityによって提供された情報に基づくFC Frame Receiver PortalでFibre Channelメカニズムを使用します。 FCIP Entityはフロー制御にFC Frame Transmitter Portalで流れ規制に関してFC Entityによって提供された情報に基づくEncapsulated Frame Receiver PortalでTCPメカニズムを使用します。
Coordination of these flow control mechanisms, one of which is credit based and the other of which is window based, depends on a painstaking design that is outside the scope of this specification.
それの1つは基づくクレジットです。そのもう片方がそれによる基づく窓です。これらのフロー制御メカニズムのコーディネートはこの仕様の範囲の外にある勤勉なデザインによります。
9. Security
9. セキュリティ
FCIP utilizes the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. This section describes the requirements for various components of these protocols as used by FCIP, based on FCIP operating environments. Additional consideration for use of IPsec and IKE with the FCIP protocol can be found in [21]. In the event that requirements in [21] conflict with requirements stated in this document, the requirements in this document SHALL prevail.
FCIPは、かぎ管理プロトコルとしてデータの機密性、認証サービス、およびIKEを提供するのにIPsecプロトコル群を利用します。 FCIP操作環境に基づいてFCIPによって使用されるようにこのセクションはこれらのプロトコルの様々な成分のための要件について説明します。 [21]でFCIPプロトコルがあるIPsecとIKEの使用のための追加的約因を見つけることができます。 [21]の要件が本書では述べられている要件と闘争する場合、このドキュメントSHALLの要件は広がっています。
9.1. Threat Models
9.1. 脅威モデル
Using a general purpose, wide-area network, such as an IP Network, as a functional replacement for physical cabling introduces some security problems not normally encountered in Fibre Channel Fabrics. FC interconnect cabling is typically protected physically from outside access. Public IP Networks allow hostile parties to impact the security of the transport infrastructure.
汎用を使用して、物理的なケーブリングとの機能的な交換としてのIP Networkなどの広域ネットワークは通常、Fibre Channel Fabricsで遭遇しないいくつかの警備上の問題を紹介します。 FC内部連絡ケーブリングはアクセサリーの外から通常物理的に保護されます。 公共のIP Networksは敵対的なパーティーを輸送インフラのセキュリティに影響を与えさせます。
The general effect is that the security of an FC Fabric is only as good as the security of the entire IP Network that carries the FCIP Links used by that FC Fabric. The following broad classes of attacks are possible:
一般的効果はFC Fabricのセキュリティが単にリンクスがそのFC Fabricで使用したFCIPを運ぶ全体のIP Networkのセキュリティと同じくらい良いということです。 以下の広いクラスの攻撃は可能です:
1) Unauthorized Fibre Channel elements can gain access to resources
through normal Fibre Channel Fabric and processes. Although this
is a valid threat, securing the Fibre Channel Fabrics is outside
the scope of this document. Securing the IP Network is the issue
considered in this specification.
1) 権限のないFibre Channel要素は正常なFibre Channel Fabricとプロセスを通してリソースへのアクセスを得ることができます。 これは有効な脅威ですが、このドキュメントの範囲の外にFibre Channel Fabricsを固定するのがあります。 IP Networkを固定するのは、この仕様で考えられた問題です。
Rajagopal, et al. Standards Track [Page 38] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[38ページ]。
2) Unauthorized agents can monitor and manipulate Fibre Channel
traffic flowing over physical media used by the IP Network and
accessible to the agent.
2) 権限のないエージェントは、IP Networkによって使用された物理的なメディアの上で流れていてエージェントにとって、アクセスしやすいFibre Channelトラフィックをモニターして、操ることができます。
3) TCP Connections may be hijacked and used to instantiate an invalid
FCIP Link between two peer FCIP Entities.
3) TCPコネクションズは、2同輩FCIP Entitiesの間の無効のFCIP Linkを例示するのにハイジャックされて、使用されるかもしれません。
4) Valid and invalid FCIP Frames may be injected on the TCP
Connections.
4) 有効で無効のFCIP FramesはTCPコネクションズで注入されるかもしれません。
5) The payload of an FCIP Frame may be altered or transformed. The
TCP checksum, FCIP ones complement checks, and FC frame CRC do not
protect against this because all of them can be modified or
regenerated by a malicious and determined adversary.
5) FCIP Frameのペイロードは、変更されるか、または変えられるかもしれません。 悪意があって断固とした敵がそれらのすべてを変更するか、または作り直すことができるので、TCPチェックサム、FCIPのもの補数のチェック、およびFCフレームCRCはこれから守りません。
6) Unauthorized agents can masquerade as valid FCIP Entities and
disturb proper operation of the Fibre Channel Fabric.
6) 権限のないエージェントは、有効なFCIP Entitiesのふりをして、Fibre Channel Fabricの適切な操作を擾乱できます。
7) Denial of Service attacks can be mounted by injecting TCP
Connection requests and other resource exhaustion operations.
7) TCP Connection要求と他のリソース疲労困憊操作を注入することによって、サービス妨害攻撃を仕掛けることができます。
8) An adversary may launch a variety of attacks against the discovery
process [17].
8) 敵は発見プロセス[17]に対してさまざまな攻撃に着手するかもしれません。
9) An attacker may exploit the FSF authentication mechanism of the
FCIP Link formation process (see section 8.1.3). The attacker
could observe the FSF contents sent on an initial connection of an
FCIP Link and use the observed nonce, Source FC/FCIP Entity
Identifier, and other FSF contents to form an FCIP Link using the
attacker's own previously established connection, while
resetting/blocking the observed connection. Although the use of
timeout for reception of FSF reduces the risk of this attack, such
an attack is possible. See section 9.3.1 to protect against this
specific attack.
9) 攻撃者はFCIP Link構成プロセスのFSF認証機構を利用するかもしれません(セクション8.1.3を見てください)。 攻撃者は、FSFコンテンツが攻撃者の自己の以前に確立した接続を使用することでFCIP Linkを形成するのに観測された接続をリセットするか、または妨げている間、FCIP Linkの初期の接続を転送して、観測された一回だけ、Source FC/FCIP Entity Identifier、および他のFSFコンテンツを使用するのを観測できました。 タイムアウトのFSFのレセプションの使用はこの攻撃の危険を減少させますが、そのような攻撃は可能です。 セクション9.3.1を見て、この特定の攻撃から守ってください。
The existing IPsec Security Architecture and protocol suite [10] offers protection from these threats. An FCIP Entity MUST implement portions of the IPsec protocol suite as described in this section.
[10]が保護をこれらの脅威から提供する既存のIPsec Security Architectureとプロトコル群。 FCIP Entityはこのセクションで説明されるようにIPsecプロトコル群の一部を実装しなければなりません。
Rajagopal, et al. Standards Track [Page 39] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[39ページ]。
9.2. FC Fabric and IP Network Deployment Models
9.2. FC骨組みとIPネットワーク展開モデル
In the context of enabling a secure FCIP tunnel between FC SANs, the following characteristics of the IP Network deployment are useful to note.
FC SANsの間の安全なFCIPトンネルを可能にすることの文脈では、IP Network展開の以下の特性は、注意するために役に立ちます。
1) The FCIP Entities share a peer-to-peer relationship. Therefore,
the administration of security policies applies to all FCIP
Entities in an equal manner. This differs from a true Client-
Server relationship, where there is an inherent difference in how
security policies are administered.
1) FCIP Entitiesはピアツーピア関係を共有します。 したがって、安全保障政策の管理は等しい方法ですべてのFCIP Entitiesに適用されます。 これは本当のClientサーバ関係と異なっています。そこに、安全保障政策がどう管理されるか固有の違いがあります。
2) Policy administration as well as security deployment and
configuration are constrained to the set of FCIP Entities, thereby
posing less of a requirement on a scalable mechanism. For
example, the validation of credentials can be relaxed to the point
where deploying a set of pre-shared keys is a viable technique.
2) セキュリティ展開と同様に方針管理と構成はFCIP Entitiesのセットに抑制されます、その結果、スケーラブルなメカニズムに関する要件の以下にポーズをとらせます。 例えば、資格証明書の合法化は1セットのあらかじめ共有されたキーを配布するのが、実行可能なテクニックであるポイントにリラックスできます。
3) TCP Connections and the IP Network are terminated at the FCIP
Entity. The granularity of security implementation is at the
level of the FCIP tunnel endpoint (or FCIP Entity), unlike other
applications where there is a user-level termination of TCP
Connections. User-level objects are not controllable by or
visible to FCIP Entities. All user-level security related to FCIP
is the responsibility of the Fibre Channel standards and is
outside the scope of this specification.
3) TCPコネクションズとIP NetworkはFCIP Entityで終えられます。 セキュリティ実装の粒状がFCIPトンネル終点(または、FCIP Entity)のレベルにあります、TCPコネクションズのユーザレベル終了がある他のアプリケーションと異なって。 ユーザレベルオブジェクトは、FCIP Entitiesに制御可能でなく、また目に見えません。 FCIPに関連するすべてのユーザーレベルのセキュリティは、Fibre Channel規格の責任であり、この仕様の範囲の外にあります。
4) When an FCIP Entity is deployed, its IP addresses will typically
be statically assigned. However, support for dynamic IP address
assignment, as described in [33], while typically not required,
cannot be ruled out.
4) FCIP Entityが配布されるとき、IPアドレスは静的に通常割り当てられるでしょう。 しかしながら、通常必要でない間、[33]で説明される動的IPアドレス課題のサポートは除外できません。
9.3. FCIP Security Components
9.3. FCIPセキュリティの部品
FCIP Security compliant implementations MUST implement ESP and the IPsec protocol suite based cryptographic authentication and data integrity [10], as well as confidentiality using algorithms and transforms as described in this section. Also, FCIP implementations MUST meet the secure key management requirements of IPsec protocol suite.
FCIP Security対応することの実装が超能力を実装しなければならなくて、IPsecプロトコル群は、暗号の認証、データ保全[10]、およびアルゴリズムを使用する秘密性を基礎づけて、このセクションで説明されるように変形します。 また、FCIP実装はIPsecプロトコル群の安全なかぎ管理必要条件を満たさなければなりません。
9.3.1. IPsec ESP Authentication and Confidentiality
9.3.1. IPsec超能力認証と秘密性
FCIP Entities MUST implement IPsec ESP [12] in Tunnel Mode for providing Data Integrity and Confidentiality. FCIP Entities MAY implement IPsec ESP in Transport Mode, if deployment considerations require use of Transport Mode. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
FCIP Entitiesは、データの保全とConfidentialityを提供するためにIPsecがトンネル・モードで超能力[12]であると実装しなければなりません。 展開問題がTransport Modeの使用を必要とするなら、FCIP Entitiesは、IPsecがTransport Modeの超能力であると実装するかもしれません。 超能力が利用されているとき、1パケットあたりのデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
Rajagopal, et al. Standards Track [Page 40] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[40ページ]。
If Confidentiality is not enabled but Data Integrity is enabled, ESP with NULL Encryption [15] MUST be used.
Confidentialityが有効にされませんが、データの保全が可能にされるなら、NULL Encryption[15]がある超能力を使用しなければなりません。
IPsec ESP for message authentication computes a cryptographic hash over the payload that is protected. While IPsec ESP mandates compliant implementations to support certain algorithms for deriving this hash, FCIP implementations:
IPsec、通報認証のための超能力は暗号のハッシュを保護されるペイロードの上計算します。 IPsecである間、超能力はこのハッシュを引き出すためのあるアルゴリズムをサポートするために対応する実装を強制して、FCIPは実装です:
- MUST implement HMAC with SHA-1 [11] - SHOULD implement AES in CBC MAC mode with XCBC extensions [23] - DES in CBC mode SHOULD NOT be used due to inherent weaknesses
- 固有の弱点のためSHA-1[11]と道具HMAC--XCBC拡張子[23]があるCBC MACモードによるSHOULD道具AES--CBCモードSHOULD NOTによるDESを使用しなければなりませんか?
For ESP Confidentiality, FCIP Entities:
超能力秘密性、FCIP実体のために:
- MUST implement 3DES in CBC mode [16] - SHOULD implement AES in CTR mode [22] - MUST implement NULL Encryption [15]
- 中のSHOULDがCTRモード[22]でAESを実装するというCBCモード[16]がそうしなければならない道具3DESはNULL Encryptionを実装しなければなりませんか?[15]
9.3.2. Key Management
9.3.2. Key Management
FCIP Entities MUST support IKE [14] for peer authentication, negotiation of Security Associations (SA), and Key Management using the IPsec DOI [13]. Manual keying SHALL NOT be used for establishing an SA since it does not provide the necessary elements for rekeying (see section 9.3.3). Conformant FCIP implementations MUST support peer authentication using pre-shared keys and MAY support peer authentication using digital certificates. Peer authentication using public key encryption methods outlined in IKE [14] sections 5.2 and 5.3 SHOULD NOT be used.
IPsec DOI[13]を使用して、FCIP Entitiesは、IKEが同輩認証、Security Associations(SA)の交渉、およびKey Managementのための[14]であるとサポートしなければなりません。 手動、SHALL NOTを合わせて、必要な要素を「再-合わせ」るのに提供しないので(セクション9.3.3を見てください)SAを設立するのに使用されてください。 デジタル証明書を使用して、Conformant FCIP実装は同輩認証があらかじめ共有されたキーを使用して、5月のサポート同輩認証であるとサポートしなければなりません。 公開鍵暗号化メソッドを使用する同輩認証がIKE[14]セクション5.2と5.3でSHOULD NOTについて概説しました。使用されます。
IKE Phase 1 establishes a secure, MAC-authenticated channel for communications for use by IKE Phase 2. FCIP implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode.
IKE Phase1はIKE Phase2による使用のためにコミュニケーションのために安全で、MACによって認証されたチャンネルを確立します。 FCIP実装はIKE Main ModeとSHOULDサポートAggressive Modeをサポートしなければなりません。
IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conformant FCIP 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, and 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 [13], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
IKE Phase1交換は明らかに、Identification有効搭載量野原(IDiiとIDir)を運ばなければなりません。 Conformant FCIP実装は__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値を使用してはいけません。 [13]で説明されるように、Identification有効搭載量におけるポートとプロトコル分野はゼロへのセットであるに違いありませんかUDPが500を移植します。
FCIP Entities negotiate parameters for SA during IKE Phase 2 only using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode", there is no requirement for PFS (Perfect Forward Secrecy). FCIP
FCIP Entitiesは、IKE Phase2の間、「迅速なモード」を使用するだけであることでSAのためのパラメタを交渉します。 IKE「迅速なモード」に従事しているFCIP Entitiesのために、PFS(完全なForward Secrecy)のための要件は全くありません。 FCIP
Rajagopal, et al. Standards Track [Page 41] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[41ページ]。
implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (based on the version of IP supported). Other Identification Type values MUST NOT be used.
実装はIPV4_ADDRかID_IPV6_ADDR Identification Typeが評価する(サポートされたIPのバージョンに基づいています)ID_を使用しなければなりません。 他のIdentification Type値を使用してはいけません。
Since the number of Phase 2 SAs may be limited, Phase 2 delete messages may be sent for idle SAs. The receipt of a Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down an FCIP Link or any of its TCP connections. When there is new activity on that idle link, a new Phase 2 SA MUST be re-established.
Phase2SAsの数が制限されるかもしれないので、Phase2はメッセージを削除します。使用されていないSAsのために送るかもしれません。 Phase2の領収書はメッセージSHOULD NOTを削除します。FCIP Linkを取りこわす理由として解釈されていてTCP接続のいずれになってくださいも。 いつに、新しい活動がそんなに使用されていないリンク、新しいPhase2SA MUSTにあるか。復職します。
For a given pair of FCIP Entities, the same IKE Phase 1 negotiation can be used for all Phase 2 negotiations; i.e., all TCP Connections that are bundled into the single FCIP Link can share the same Phase 1 results.
FCIP Entitiesの与えられた組において、すべてのPhase2交渉に同じIKE Phase1交渉を使用できます。 独身のFCIP Linkに投げ込まれるすなわちすべてのTCPコネクションズが同じPhase1結果を共有できます。
Repeated rekeying using "Quick Mode" on the same shared secret will reduce the cryptographic properties of that secret over time. To overcome this, Phase 1 SHOULD be invoked periodically to create a new set of IKE shared secrets and related security parameters.
同じ共有秘密キーの「迅速なモード」を使用する繰り返された「再-合わせ」るのが時間がたつにつれて、その秘密の暗号の特性を減少させるでしょう。 これに打ち勝ってください、Phase。1SHOULDが新しいIKE共有秘密キーを作成するために定期的に呼び出されて、セキュリティパラメタについて話しました。
IKE Phase 1 establishment requires the following key distribution and FCIP Entities:
IKE Phase1設立は以下の主要な分配とFCIP Entitiesを必要とします:
- MUST support pre-shared IKE keys.
- MAY support certificate-based peer authentication using digital
signatures.
- SHOULD NOT use peer authentication using the public key encryption
methods outlined in sections 5.2 and 5.3 of [14].
- あらかじめ共有されたIKEキーを支えなければなりません。 - デジタル署名を使用して、証明書ベースの同輩認証をサポートするかもしれません。 - SHOULD NOTは、[14]のセクション5.2と5.3で概説された公開鍵暗号化メソッドを使用することで同輩認証を使用します。
When pre-shared keys are used, IKE Main Mode is usable only when both peers of an FCIP Link use statically assigned IP addresses. When support for dynamically assigned IP Addresses is attempted in conjunction with Main Mode, use of group pre-shared keys would be forced, and the use of group pre-shared keys in combination with Main Mode is not recommended as it exposes the deployed environment to man-in-the-middle attacks. Therefore, if either peer of an FCIP Link uses dynamically assigned addresses, Aggressive Mode SHOULD be used and Main Mode SHOULD NOT be used.
あらかじめ共有されたキーが使用されているとき、FCIP Link使用の両方の同輩が静的にIPアドレスを割り当てたときだけ、IKE Main Modeは使用可能です。 ダイナミックに割り当てられたIP Addressesのサポートが試みられるとき、Main Mode、あらかじめ共有されたグループの使用に関連してキーは押し込まれるでしょう、そして、介入者攻撃への配布している環境を暴露するとき、Main Modeと組み合わせたグループのあらかじめ共有されたキーの使用は推薦されません。 したがって、用途がダイナミックにアドレス、Aggressive Mode SHOULDを割り当てたFCIP Linkのどちらかの同輩が中古、そして、Main Mode SHOULD NOTであるなら、使用されてください。
When Digital Signatures are used, either IKE Main Mode or IKE Aggressive Mode may be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) MUST be suitably restricted, since compromise of secret information nullifies the security properties of IKE/IPsec protocols. Such mechanisms are outside the scope of this document. Support for IKE Oakley Groups [27] is not required.
Digital Signaturesが使用されているとき、IKE Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 すべての場合では、適当に局所的に保存された秘密の情報(あらかじめ共有されたキー、またはデジタル署名のための秘密鍵)へのアクセスを制限しなければなりません、秘密の情報の感染がIKE/IPsecプロトコルのセキュリティの特性を無効にするので。 このドキュメントの範囲の外にそのようなメカニズムがあります。 IKEオークリーGroups[27]のサポートは必要ではありません。
Rajagopal, et al. Standards Track [Page 42] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[42ページ]。
For the purpose of establishing a secure FCIP Link, the two participating FCIP Entities consult a Security Policy Database (SPD). The SPD is described in IPsec [10] Section 4.4.1. FCIP Entities may have more than one interface and IP Address, and it is possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is established for each FCIP endpoint IP Address pair. Within IKE Phase 1, FCIP implementations must support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are dynamically assigned, it may be beneficial to use ID_FQDN, and for this reason, IP_FQDN Identity Payload MUST be supported. Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID) SHOULD NOT be used.
安全なFCIP Linkを設立する目的のために、2参加FCIP EntitiesがSecurity Policy Database(SPD)に相談します。 SPDはIPsec[10]セクション4.4.1で説明されます。 FCIP Entitiesには複数のTCP接続を含むFCIP Linkに、可能なFCIP終点が1つのインタフェース、IP Address、およびそれよりあるかもしれません。IP Addressesは異なっています。 この場合、IKE Phase1SAはそれぞれのFCIP終点IP Address組のために設立されます。 IKE Phase1の中では、FCIP実装は、__ID IPV4_ADDR、ID IPV6_ADDR(プロトコル・スタックがIPv6をサポートするなら)、およびID_FQDN Identityが有効搭載量であるとサポートしなければなりません。 FCIP Endpointアドレスがダイナミックに割り当てられるなら、ID_FQDNを使用するのが有益であるかもしれなく、この理由で、IP_FQDN Identity有効搭載量をサポートしなければなりません。 他のアイデンティティペイロード(__ID USER_FQDN、ID DER_ASN1__GN、ID KEY_ID)SHOULD NOT、使用されてください。
At the end of successful IKE negotiations both FCIP Entities store the SA parameters in their SA database (SAD). The SAD is described in IPsec [10] Section 4.4.3. The SAD contains the set of active SA entries, each entry containing Sequence Counter Overflow, Sequence Number Counter, Anti-replay Window, and the Lifetime of the SA. FCIP Entities SHALL employ a default SA Lifetime of one hour and a default Anti-replay window of 32 sequence numbers.
At the end of successful IKE negotiations both FCIP Entities store the SA parameters in their SA database (SAD). The SAD is described in IPsec [10] Section 4.4.3. The SAD contains the set of active SA entries, each entry containing Sequence Counter Overflow, Sequence Number Counter, Anti-replay Window, and the Lifetime of the SA. FCIP Entities SHALL employ a default SA Lifetime of one hour and a default Anti-replay window of 32 sequence numbers.
When a TCP Connection is established between two FCIP_DEs, two unidirectional SAs are created for that connection and each SA is identified in the form of a Security Parameter Index (SPI). One SA is associated with the incoming traffic flow and the other SA is associated with the outgoing traffic flow. The FCIP_DEs at each end of the TCP connection MUST maintain the SPIs for both its incoming and outgoing FCIP Encapsulated Frames.
When a TCP Connection is established between two FCIP_DEs, two unidirectional SAs are created for that connection and each SA is identified in the form of a Security Parameter Index (SPI). One SA is associated with the incoming traffic flow and the other SA is associated with the outgoing traffic flow. The FCIP_DEs at each end of the TCP connection MUST maintain the SPIs for both its incoming and outgoing FCIP Encapsulated Frames.
FCIP Entities MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
FCIP Entities MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
9.3.3. ESP Replay Protection and Rekeying Issues
9.3.3. ESP Replay Protection and Rekeying Issues
FCIP Entities MUST implement Replay Protection against ESP Sequence Number wrap, as described in [14]. In addition, based on the cipher algorithm and the number of bits in the cipher block size, the validity of the key may become compromised. In both cases, the SA needs to be re-established.
FCIP Entities MUST implement Replay Protection against ESP Sequence Number wrap, as described in [14]. In addition, based on the cipher algorithm and the number of bits in the cipher block size, the validity of the key may become compromised. In both cases, the SA needs to be re-established.
FCIP Entities MUST use the results of IKE Phase 1 negotiation for initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs.
FCIP Entities MUST use the results of IKE Phase 1 negotiation for initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs.
Rajagopal, et al. Standards Track [Page 43] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 43] RFC 3821 FCIP July 2004
To enable smooth transition of SAs, it is RECOMMENDED that both FCIP Entities refresh the SPI when the sequence number counter reaches 2^31 (i.e., half the sequence number space). It also is RECOMMENDED that the receiver operate with multiple SPIs for the same TCP Connection for a period of 2^31 sequence number packets before aging out an SPI.
To enable smooth transition of SAs, it is RECOMMENDED that both FCIP Entities refresh the SPI when the sequence number counter reaches 2^31 (i.e., half the sequence number space). It also is RECOMMENDED that the receiver operate with multiple SPIs for the same TCP Connection for a period of 2^31 sequence number packets before aging out an SPI.
When a new SPI is created for the outgoing direction, the sending side SHALL begin using it for all new FCIP Encapsulated Frames. Frames that are either in-flight, or re-sent due to TCP retransmissions, etc. MAY use either the new SPI or the one being replaced.
When a new SPI is created for the outgoing direction, the sending side SHALL begin using it for all new FCIP Encapsulated Frames. Frames that are either in-flight, or re-sent due to TCP retransmissions, etc. MAY use either the new SPI or the one being replaced.
9.4. Secure FCIP Link Operation
9.4. Secure FCIP Link Operation
9.4.1. FCIP Link Initialization Steps
9.4.1. FCIP Link Initialization Steps
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. If enabled, the following FCIP Link Initialization steps MUST be followed.
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. If enabled, the following FCIP Link Initialization steps MUST be followed.
When an FCIP Link is initialized, before any FCIP TCP Connections are established, the local SPD is consulted to determine if IKE Phase 1 has been completed with the FCIP Entity in the peer FCIP Entity, as identified by the WWN.
When an FCIP Link is initialized, before any FCIP TCP Connections are established, the local SPD is consulted to determine if IKE Phase 1 has been completed with the FCIP Entity in the peer FCIP Entity, as identified by the WWN.
If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise, IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1 fails, the FCIP Link initialization terminates and notifies the FC entity with the reason for the termination. Otherwise, the FCIP Link initialization moves to TCP Connection Initialization.
If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise, IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1 fails, the FCIP Link initialization terminates and notifies the FC entity with the reason for the termination. Otherwise, the FCIP Link initialization moves to TCP Connection Initialization.
As described in section 8.1, FCIP Entities exchange an FSF for forming an FCIP Link. The use of ESP Confidentiality is an effective countermeasure against any perceived security risks of FSF.
As described in section 8.1, FCIP Entities exchange an FSF for forming an FCIP Link. The use of ESP Confidentiality is an effective countermeasure against any perceived security risks of FSF.
9.4.2. TCP Connection Security Associations (SAs)
9.4.2. TCP Connection Security Associations (SAs)
Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. While it is possible for an IKE Phase 2 SA to protect multiple TCP connections, all packets of a TCP connection are protected using only one IKE Phase 2 SA.
Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. While it is possible for an IKE Phase 2 SA to protect multiple TCP connections, all packets of a TCP connection are protected using only one IKE Phase 2 SA.
Rajagopal, et al. Standards Track [Page 44] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 44] RFC 3821 FCIP July 2004
If different Quality of Service settings are applied to TCP connections, it is advisable to use a different IPsec SA for these connections. Attempting to apply a different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For additional details, see [21].
If different Quality of Service settings are applied to TCP connections, it is advisable to use a different IPsec SA for these connections. Attempting to apply a different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For additional details, see [21].
FCIP implementations need not verify that the IP addresses and port numbers in the packet match any locally stored per-connection values, leaving this check to be performed by the IPsec layer.
FCIP implementations need not verify that the IP addresses and port numbers in the packet match any locally stored per-connection values, leaving this check to be performed by the IPsec layer.
An implementation is free to perform several IKE Phase 2 negotiations and cache them in its local SPIs, although entries in such a cache can be flushed per current SA Lifetime settings.
An implementation is free to perform several IKE Phase 2 negotiations and cache them in its local SPIs, although entries in such a cache can be flushed per current SA Lifetime settings.
9.4.3. Handling Data Integrity and Confidentiality Violations
9.4.3. Handling Data Integrity and Confidentiality Violations
Upon datagram reception, when the ESP packet fails an integrity check, the receiver MUST drop the datagram, which will trigger TCP retransmission. If many such datagrams are dropped, a receiving FCIP Entity MAY close the TCP Connection and notify the FC Entity with the reason for the closure.
Upon datagram reception, when the ESP packet fails an integrity check, the receiver MUST drop the datagram, which will trigger TCP retransmission. If many such datagrams are dropped, a receiving FCIP Entity MAY close the TCP Connection and notify the FC Entity with the reason for the closure.
An implementation SHOULD follow guidelines for auditing all auditable ESP events per IPsec [10] Section 7.
An implementation SHOULD follow guidelines for auditing all auditable ESP events per IPsec [10] Section 7.
Integrity checks MUST be performed if Confidentiality is enabled.
Integrity checks MUST be performed if Confidentiality is enabled.
10. Performance
10. Performance
10.1. Performance Considerations
10.1. Performance Considerations
Traditionally, the links between FC Fabric components have been characterized by low latency and high throughput. The purpose of FCIP is to provide functionality equivalent to these links using an IP Network, where low latency and high throughput are not as certain. It follows that FCIP Entities and their counterpart FC Entities probably will be interested in optimal use of the IP Network.
Traditionally, the links between FC Fabric components have been characterized by low latency and high throughput. The purpose of FCIP is to provide functionality equivalent to these links using an IP Network, where low latency and high throughput are not as certain. It follows that FCIP Entities and their counterpart FC Entities probably will be interested in optimal use of the IP Network.
Many options exist for ensuring high throughput and low latency appropriate for the distances involved in an IP Network. For example, a private IP Network might be constructed for the sole use of FCIP Entities. The options that are within the scope of this specification are discussed here.
Many options exist for ensuring high throughput and low latency appropriate for the distances involved in an IP Network. For example, a private IP Network might be constructed for the sole use of FCIP Entities. The options that are within the scope of this specification are discussed here.
One option for increasing the probability that FCIP data streams will experience low latency and high throughput is the IP QoS techniques discussed in section 10.2. This option can have value when applied
One option for increasing the probability that FCIP data streams will experience low latency and high throughput is the IP QoS techniques discussed in section 10.2. This option can have value when applied
Rajagopal, et al. Standards Track [Page 45] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 45] RFC 3821 FCIP July 2004
to a single TCP Connection. Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics.
to a single TCP Connection. Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics.
There are many reasons why an FC Entity might request the creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated services for different TCP data connections between FCIP_LEPs, or a preference to separately queue different streams of traffic not having a common in-order delivery requirement.
There are many reasons why an FC Entity might request the creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated services for different TCP data connections between FCIP_LEPs, or a preference to separately queue different streams of traffic not having a common in-order delivery requirement.
At the time a new TCP Connection is created, the FC Entity SHALL specify to the FCIP Entity the QoS characteristics (including but not limited to IP per-hop-behavior) to be used for the lifetime of that connection. This MAY be achieved by having:
At the time a new TCP Connection is created, the FC Entity SHALL specify to the FCIP Entity the QoS characteristics (including but not limited to IP per-hop-behavior) to be used for the lifetime of that connection. This MAY be achieved by having:
a) only one set of QoS characteristics for all TCP Connections;
a) only one set of QoS characteristics for all TCP Connections;
b) a default set of QoS characteristics that the FCIP Entity applies
in the absence of differing instructions from the FC Entity; or
b) a default set of QoS characteristics that the FCIP Entity applies in the absence of differing instructions from the FC Entity; or
c) a sophisticated mechanism for exchanging QoS requirements
information between the FC Entity and FCIP Entity each time a new
TCP Connection is created.
c) a sophisticated mechanism for exchanging QoS requirements information between the FC Entity and FCIP Entity each time a new TCP Connection is created.
Once established, the QoS characteristics of a TCP Connection SHALL NOT be changed, since this specification provides no mechanism for the FC Entity to control such changes. The mechanism for providing different QoS characteristics in FCIP is the establishment of a different TCP Connections and associated FCIP_DEs.
Once established, the QoS characteristics of a TCP Connection SHALL NOT be changed, since this specification provides no mechanism for the FC Entity to control such changes. The mechanism for providing different QoS characteristics in FCIP is the establishment of a different TCP Connections and associated FCIP_DEs.
When FCIP is used with a network with a large (bandwidth*delay) product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms (window scaling and wrapped sequence protection) for Long Fat Networks (LFNs) as defined in RFC 1323 [24].
When FCIP is used with a network with a large (bandwidth*delay) product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms (window scaling and wrapped sequence protection) for Long Fat Networks (LFNs) as defined in RFC 1323 [24].
10.2. IP Quality of Service (QoS) Support
10.2. IP Quality of Service (QoS) Support
Many methods of providing QoS have been devised or proposed. These include (but are not limited to) the following:
Many methods of providing QoS have been devised or proposed. These include (but are not limited to) the following:
- Multi-Protocol Label Switching (MPLS) -- RFC 3031 [32]
- Differentiated Services Architecture (diffserv) -- RFC 2474 [28],
RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and other forms
of per-hop-behavior (PHB)
- Integrated Services, RFC 1633 [25]
- IEEE 802.1p
- Multi-Protocol Label Switching (MPLS) -- RFC 3031 [32] - Differentiated Services Architecture (diffserv) -- RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and other forms of per-hop-behavior (PHB) - Integrated Services, RFC 1633 [25] - IEEE 802.1p
Rajagopal, et al. Standards Track [Page 46] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 46] RFC 3821 FCIP July 2004
The purpose of this specification is not to specify any particular form of IP QoS, but rather to specify only those issues that must be addressed in order to maximize interoperability between FCIP equipment that has been manufactured by different vendors.
The purpose of this specification is not to specify any particular form of IP QoS, but rather to specify only those issues that must be addressed in order to maximize interoperability between FCIP equipment that has been manufactured by different vendors.
It is RECOMMENDED that some form of preferential QoS be used for FCIP traffic to minimize latency and packet drops. No particular form of QoS is recommended.
It is RECOMMENDED that some form of preferential QoS be used for FCIP traffic to minimize latency and packet drops. No particular form of QoS is recommended.
If a PHB IP QoS is implemented, it is RECOMMENDED that it interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31]).
If a PHB IP QoS is implemented, it is RECOMMENDED that it interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31]).
If no form of preferential QoS is implemented, the DSCP field SHOULD be set to '000000' to avoid negative impacts on other network components and services that may be caused by uncontrolled usage of non-zero values of the DSCP field.
If no form of preferential QoS is implemented, the DSCP field SHOULD be set to '000000' to avoid negative impacts on other network components and services that may be caused by uncontrolled usage of non-zero values of the DSCP field.
11. References
11. References
11.1. Normative References
11.1. Normative References
The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents and looking for newer reference documents is recommended.
The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents and looking for newer reference documents is recommended.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December
12, 2001.
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December 12, 2001.
[3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
25, 2003.
[3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003.
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001,
December 12, 2001.
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001, December 12, 2001.
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI
INCITS.373:2003, October 27, 2003.
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003.
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
Rajagopal, et al. Standards Track [Page 47] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 47] RFC 3821 FCIP July 2004
[7] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[10] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing
for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[13] Piper, D., "The Internet IP Security Domain of Interpretation of
ISAKMP", RFC 2407, November 1998.
[13] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
RFC 2451, November 1998.
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, version 2", RFC 2608, July 1999.
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK
Extension", RFC 2883, July 2000.
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK Extension", RFC 2883, July 2000.
[19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia,
C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC
3643, December 2003.
[19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities
Using Service Location Protocol version 2 (SLPv2)", RFC 3822,
July 2004.
[20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004.
[21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino,
"Securing Block Storage Protocols over IP", RFC 3723, April
2004.
[21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
Rajagopal, et al. Standards Track [Page 48] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 48] RFC 3821 FCIP July 2004
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
Its Use With IPsec", RFC 3566, September 2003.
[23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
11.2. Informative References
11.2. Informative References
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
November 1998.
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
Ipv6 Headers", RFC 2474, December 1998.
[28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers", RFC 2474, December 1998.
[29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An
Assured Forwarding PHB", RFC 2597, June 1999.
[30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An Assured Forwarding PHB", RFC 2597, June 1999.
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB Group", RFC 2598, June 1999.
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB Group", RFC 2598, June 1999.
[32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January, 2001.
[32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January, 2001.
[33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel
Mode", RFC 3456, January 2003.
[33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive
Introduction", Northwest Learning Associates, 1998.
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998.
Rajagopal, et al. Standards Track [Page 49] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 49] RFC 3821 FCIP July 2004
12. Acknowledgments
12. Acknowledgments
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues.
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues.
The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
Rajagopal, et al. Standards Track [Page 50] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 50] RFC 3821 FCIP July 2004
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different.
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different.
Fibre Channel bit and byte numbering can be observed if the data structure heading, shown in figure 11, is cut and pasted at the top of figure 7, figure 9, and figure 17.
Fibre Channel bit and byte numbering can be observed if the data structure heading, shown in figure 11, is cut and pasted at the top of figure 7, figure 9, and figure 17.
W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Figure 11: Fibre Channel Data Structure Bit and Byte Numbering
Figure 11: Fibre Channel Data Structure Bit and Byte Numbering
Fibre Channel bit numbering for the pFlags field can be observed if the data structure heading, shown in figure 12, is cut and pasted at the top of figure 8.
Fibre Channel bit numbering for the pFlags field can be observed if the data structure heading, shown in figure 12, is cut and pasted at the top of figure 8.
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
|----------------Bit--------------------| | | | 31 30 29 28 27 26 25 24 |
Figure 12: Fibre Channel pFlags Bit Numbering
Figure 12: Fibre Channel pFlags Bit Numbering
Fibre Channel bit numbering for the Connection Usage Flags field can be observed if the data structure heading, shown in figure 13, is cut and pasted at the top of figure 10.
Fibre Channel bit numbering for the Connection Usage Flags field can be observed if the data structure heading, shown in figure 13, is cut and pasted at the top of figure 10.
|------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 |
|------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 |
Figure 13: Fibre Channel Connection Usage Flags Bit Numbering
Figure 13: Fibre Channel Connection Usage Flags Bit Numbering
Appendix B - IANA Considerations
Appendix B - IANA Considerations
IANA has made the following port assignments to FCIP:
IANA has made the following port assignments to FCIP:
- fcip-port 3225/tcp FCIP
- fcip-port 3225/udp FCIP
- fcip-port 3225/tcp FCIP - fcip-port 3225/udp FCIP
IANA has changed the authority for these port allocations to reference this RFC.
IANA has changed the authority for these port allocations to reference this RFC.
Use of UDP with FCIP is prohibited even though IANA has allocated a port.
Use of UDP with FCIP is prohibited even though IANA has allocated a port.
Rajagopal, et al. Standards Track [Page 51] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 51] RFC 3821 FCIP July 2004
The FC Frame encapsulation used by this specification employs Protocol# value 1, as described in the IANA Considerations appendix of the FC Frame Encapsulation [19] specification.
The FC Frame encapsulation used by this specification employs Protocol# value 1, as described in the IANA Considerations appendix of the FC Frame Encapsulation [19] specification.
Appendix C - FCIP Usage of Addresses and Identifiers
Appendix C - FCIP Usage of Addresses and Identifiers
In support of network address translators, FCIP does not use IP Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP Addresses for identification occurs when initiating new TCP connect requests (see section 8.1.2.3) where the IP Address destination of the TCP connect request is used to answer the question: "Have previous TCP connect requests been made to the same destination FCIP Entity?" The correctness of this assumption is further checked by sending the Destination FC Fabric Entity World Wide Name in the FCIP Special Frame (FSF) and having the value checked by the FCIP Entity that receives the TCP connect request and FSF (see section 8.1.3).
In support of network address translators, FCIP does not use IP Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP Addresses for identification occurs when initiating new TCP connect requests (see section 8.1.2.3) where the IP Address destination of the TCP connect request is used to answer the question: "Have previous TCP connect requests been made to the same destination FCIP Entity?" The correctness of this assumption is further checked by sending the Destination FC Fabric Entity World Wide Name in the FCIP Special Frame (FSF) and having the value checked by the FCIP Entity that receives the TCP connect request and FSF (see section 8.1.3).
For the purposes of processing incoming TCP connect requests, the source FCIP Entity is identified by the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent from the TCP connect requestor to the TCP connect recipient as the first bytes following the TCP connect request (see section 8.1.2.3 and section 8.1.3).
For the purposes of processing incoming TCP connect requests, the source FCIP Entity is identified by the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent from the TCP connect requestor to the TCP connect recipient as the first bytes following the TCP connect request (see section 8.1.2.3 and section 8.1.3).
FC-BB-2 [3] provides the definitions for each of the following FSF fields:
FC-BB-2 [3] provides the definitions for each of the following FSF fields:
- Source FC Fabric Entity World Wide Name,
- Source FC/FCIP Entity Identifier, and
- Destination FC Fabric Entity World Wide Name.
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
As described in section 8.1.3, FCIP Entities segregate their FCIP_LEPs between:
As described in section 8.1.3, FCIP Entities segregate their FCIP_LEPs between:
- Connections resulting from TCP connect requests initiated by the
FCIP Entity, and
- Connections resulting from TCP connect requests initiated by the FCIP Entity, and
- Connections resulting from TCP connect requests received by the
FCIP Entity.
- Connections resulting from TCP connect requests received by the FCIP Entity.
Within each of these two groups, the following information is used to further identify each FCIP_LEP:
Within each of these two groups, the following information is used to further identify each FCIP_LEP:
- Source FC Fabric Entity World Wide Name,
- Source FC/FCIP Entity Identifier, and
- Destination FC Fabric Entity World Wide Name.
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
Rajagopal, et al. Standards Track [Page 52] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 52] RFC 3821 FCIP July 2004
Appendix D - Example of Synchronization Recovery Algorithm
Appendix D - Example of Synchronization Recovery Algorithm
The contents of this annex are informative.
The contents of this annex are informative.
Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex.
Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex.
This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers.
This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers.
Consider the case shown in figure 14. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH.
Consider the case shown in figure 14. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH.
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
|L| |S| |S| |S| |S| |L| |S|
|F| |F| |F| |F| |F| |F| |F|...
|H| |H| |H| |H| |H| |H| |H|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
| |
|<---------2176 bytes-------->|
+-+--+-+----+-+----+-+----+-+-+-+---+-+--- |L| |S| |S| |S| |S| |L| |S| |F| |F| |F| |F| |F| |F| |F|... |H| |H| |H| |H| |H| |H| |H| +-+--+-+----+-+----+-+----+-+-+-+---+-+--- | | |<---------2176 bytes-------->|
Figure 14: Example of resynchronization data stream
Figure 14: Example of resynchronization data stream
A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream.
A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream.
Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Frame Transmitter Portal because, until synchronization is completely established, there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that
Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Frame Transmitter Portal because, until synchronization is completely established, there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that
Rajagopal, et al. Standards Track [Page 53] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 53] RFC 3821 FCIP July 2004
points exactly to the beginning of an LFH. The LFH would identify the correct beginning of a transmitted FCIP Frame, but that in no way guarantees that the SFH was also a correct FCIP Frame header.
points exactly to the beginning of an LFH. The LFH would identify the correct beginning of a transmitted FCIP Frame, but that in no way guarantees that the SFH was also a correct FCIP Frame header.
There exist some data streams that cannot be resynchronized by this algorithm. If such a data stream is encountered, the algorithm causes the TCP Connection to be closed.
There exist some data streams that cannot be resynchronized by this algorithm. If such a data stream is encountered, the algorithm causes the TCP Connection to be closed.
The resynchronization assumes that security and authentication procedures outside the FCIP Entity are protecting the valid data stream from being replaced by an intruding data stream containing valid FCIP data.
The resynchronization assumes that security and authentication procedures outside the FCIP Entity are protecting the valid data stream from being replaced by an intruding data stream containing valid FCIP data.
The following steps are one example of how an FCIP_DE might resynchronize with the data stream entering the Encapsulated Frame Receiver Portal.
The following steps are one example of how an FCIP_DE might resynchronize with the data stream entering the Encapsulated Frame Receiver Portal.
1) Search for candidate and strong headers:
1) Search for candidate and strong headers:
The data stream entering the Encapsulated Frame Receiver Portal is
searched for 12 bytes in a row containing the required values for:
The data stream entering the Encapsulated Frame Receiver Portal is searched for 12 bytes in a row containing the required values for:
a) Protocol field,
b) Version field,
c) ones complement of the Protocol field,
d) ones complement of the Version field,
e) replication of encapsulation word 0 in word 1, and
f) pFlags field and its ones complement.
a) Protocol field, b) Version field, c) ones complement of the Protocol field, d) ones complement of the Version field, e) replication of encapsulation word 0 in word 1, and f) pFlags field and its ones complement.
If such a 12-byte grouping is found, the FCIP_DE assumes that it
has identified bytes 0-2 of a candidate FCIP encapsulation header.
If such a 12-byte grouping is found, the FCIP_DE assumes that it has identified bytes 0-2 of a candidate FCIP encapsulation header.
All bytes up to and including the candidate header byte are
discarded.
All bytes up to and including the candidate header byte are discarded.
If no candidate header has been found after searching a specified
number of bytes greater than some multiple of 2176 (the maximum
length of an FCIP Frame), resynchronization has failed and the
TCP/IP connection is closed.
If no candidate header has been found after searching a specified number of bytes greater than some multiple of 2176 (the maximum length of an FCIP Frame), resynchronization has failed and the TCP/IP connection is closed.
Word 3 of the candidate header contains the Frame Length and Flags
fields and their ones complements. If the fields are consistent
with their ones complements, the candidate header is considered a
strong candidate header. The Frame Length field is used to
determine where in the byte stream the next strong candidate
header should be and processing continues at step 2).
Word 3 of the candidate header contains the Frame Length and Flags fields and their ones complements. If the fields are consistent with their ones complements, the candidate header is considered a strong candidate header. The Frame Length field is used to determine where in the byte stream the next strong candidate header should be and processing continues at step 2).
Rajagopal, et al. Standards Track [Page 54] RFC 3821 FCIP July 2004
Rajagopal, et al. Standards Track [Page 54] RFC 3821 FCIP July 2004
2) Use multiple strong candidate headers to locate a verified
candidate header:
2) Use multiple strong candidate headers to locate a verified candidate header:
The Frame Length in one strong candidate header is used to skip
incoming bytes until the expected location of the next strong
candidate header is reached. Then the tests described in step 1)
are applied to see if another strong candidate header has
successfully been located.
1個の有力な候補ヘッダーのFrame Lengthは、次の有力な候補ヘッダーの予想された位置に達するまで入って来るバイトをスキップするのに使用されます。 そして、ステップ1)で説明されたテストは、別の有力な候補ヘッダーが首尾よく見つけられたかどうか確認するために適用されます。
All bytes skipped and all bytes in all strong candidate headers
processed are discarded.
バイトがスキップして、すべての有力な候補ヘッダーのすべてのバイトが処理したすべてが捨てられます。
Strong candidate headers continue to be verified in this way for
at least 4352 bytes (twice the maximum length of an FCIP Frame).
If at any time a verification test fails, processing restarts at
step 1 and a retry counter is incremented. If the retry counter
exceeds 3 retries, resynchronization has failed and the TCP
Connection is closed, and the FC entity is notified with the
reason for the closure.
有力な候補ヘッダーは、この少なくとも4352バイト(FCIP Frameの最大の長さの2倍)ように確かめられ続けています。 確認試験がいつでも失敗するなら、処理はステップ1で再開します、そして、再試行カウンタは増加されています。 再試行カウンタが3つの再試行を超えているなら、再同期は失敗しました、そして、TCP Connectionは閉じられます、そして、FC実体は閉鎖の理由で通知されます。
After strong candidate headers have been verified for at least
4352 bytes, the next header identified is a verified candidate
header, and processing continues at step 3).
有力な候補ヘッダーが少なくとも4352バイト確かめられた後に、特定された次のヘッダーは確かめられた候補ヘッダーです、そして、処理はステップ3)で続きます。
Note: If a strong candidate header was part of the data content of
an FCIP Frame, the FCIP Frame defined by that or a subsequent
strong candidate header will eventually cross an actual header in
the byte stream. As a result it will either identify the actual
header as a strong candidate header or it will lose
synchronization again because of the extra 28 bytes in the length,
returning to step 1 as described above.
以下に注意してください。 有力な候補ヘッダーがFCIP Frameのデータ内容の一部であったなら、それによって定義されたFCIP Frameかその後の有力な候補ヘッダーが結局、バイト・ストリームで実際のヘッダーを越えるでしょう。 その結果、実際のヘッダーが有力な候補ヘッダーであると認識するだろうか、または長さ余分な28バイトのために再び同期を失うでしょう、上で説明されるようにステップ1に戻って。
3) Use multiple strong candidate headers to locate a verified
candidate header:
3) 複数の有力な候補ヘッダーを使用して、確かめられた候補ヘッダーの場所を見つけてください:
Incoming bytes are inspected and discarded until the next verified
candidate header is reached. Inspection of the incoming bytes
includes testing for other candidate headers using the criteria
described in step 1. Each verified candidate header is tested
against the tests listed in section 5.6.2.2 as would normally be
the case.
次の確かめられた候補ヘッダーが連絡されるまで、入って来るバイトは、点検されて、捨てられます。 入って来るバイトの点検は、他の候補ヘッダーがないかどうかステップ1で説明された評価基準を使用することでテストするのを含んでいます。 それぞれの確かめられた候補ヘッダーはテストされて、テストが通常、あってセクション5.6.2で.2を記載したということです。ケース。
Verified candidate headers continue to be located and tested in
this way for a minimum of 4352 bytes (twice the maximum length of
an FCIP Frame). If all verified candidate headers encountered are
valid, the last verified candidate header is a valid header. At
this point the FCIP_DE stops discarding bytes and begins normal
確かめられた候補ヘッダーは、最低4352バイト(FCIP Frameの最大の長さの2倍)がないかどうかこのように見つけられていて、テストされ続けています。 確かめられた候補ヘッダーが遭遇したすべてが有効であるなら、最後に確かめられた候補ヘッダーは有効なヘッダーです。 ここに、FCIP_DEはバイトを捨てるのを止めて、標準を始めます。
Rajagopal, et al. Standards Track [Page 55] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[55ページ]。
FCIP de-encapsulation, including for the first time since
synchronization was lost, delivery of FC Frames through the FC
Frame Transmitter Portal according to normal FCIP rules.
FCIP反-カプセル化、同期以来初めての包含は失われました、正常なFCIP規則に従ったFC Frame Transmitter Portalを通したFC Framesの配送。
If any verified candidate headers are invalid but meet all the
requirements of a strong candidate header, increment the retry
counter and return to step 2). If any verified candidate headers
are invalid and fail to meet the tests for a strong candidate
header, or if inspection of the bytes between verified candidate
headers discovers any candidate headers, increment the retry
counter and return to step 1. If the retry counter exceeds 4
retries, resynchronization has failed and the TCP/IP connection is
closed.
どれか確かめられた候補ヘッダーが無効ですが、有力な候補ヘッダーに関するすべての必要条件を満たすなら、再試行カウンタを増加してください、そして、ステップ2)に戻ってください。 どんな確かめられた候補ヘッダーも無効であり、有力な候補ヘッダーのためにテストに対応しないか、または確かめられた候補ヘッダーの間のバイトの点検が何か候補ヘッダーを発見するなら、再試行カウンタを増加してください、そして、ステップ1に戻ってください。 再試行カウンタが4つの再試行を超えているなら、再同期は失敗しました、そして、TCP/IP接続は閉じられます。
Rajagopal, et al. Standards Track [Page 56] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[56ページ]。
A flowchart for this algorithm can be found in figure 15.
このアルゴリズムのためのフローチャートは見つけられて、15が中で計算するということであるかもしれません。
Synchronization is lost
|
_____________v_______________
| |
| Search for candidate header |
+----------->| |
| | Found Not Found |
| | (Strong candidate) |
| |_____________________________|
| | |
| | + --------->close TCP
| _______v_____________________ Connection
| | | and notify
| | Enough strong candidate | the FC Entity
| +---->| headers identified? | with the reason
| | | | for closure
| | | No Yes |
| | | (Verified candidate) |
| | |_____________________________|
|___________________| |
^ | |
| | |
| | _______________________v_____
| | | |
| | | Enough verified candidate |
| | | headers validated? |
| | | |
| | | No Yes |
| | | (Resynchronized) |
| | |_____________________________|
| | | |
| | ______v__________ | Resume
| | | | + ---> Normal
| | | Synchronization | De-encapsulation
| | | Lost? |
| | | |
| | | No Yes |
| | |_________________|
| | | |
| |________| |
|___________________________|
同期は無くなっています。| _____________v_______________ | | | 候補ヘッダーの捜索| +----------->|、|、|、| 見つけられないで、見つけられます。| | | (有力な候補) | | |_____________________________| | | | | | + --------->の近いTCP| _______v_____________________ 接続| | | そして、通知してください。| | 十分な有力な候補| FC実体| +---->| 特定されたヘッダー? | 理由で| | | | 閉鎖のために| | | いいえ、はい| | | | (確かめられた候補) | | | |_____________________________| |___________________| | ^ | | | | | | | _______________________v_____ | | | | | | | 十分は候補について確かめました。| | | | 有効にされたヘッダー? | | | | | | | | いいえ、はい| | | | (Resynchronizedしました) | | | |_____________________________| | | | | | | ______v__________ | 履歴書| | | | + --->標準| | | 同期| 反-カプセル化| | | 無くなりますか? | | | | | | | | いいえ、はい| | | |_________________| | | | | | |________| | |___________________________|
Figure 15: Flow diagram of simple synchronization example
図15: 簡単な同期の例に関するフローチャート
Rajagopal, et al. Standards Track [Page 57] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[57ページ]。
Appendix E - Relationship between FCIP and IP over FC (IPFC)
付録E--FCの上のFCIPとIPとの関係(IPFC)
The contents of this annex are informative.
この別館の内容は有益です。
IPFC (RFC 2625) describes the encapsulation of IP packets in FC Frames. It is intended to facilitate IP communication over an FC network.
IPFC(RFC2625)はFC FramesでIPパケットのカプセル化について説明します。 FCネットワークの上でIPコミュニケーションを容易にするのは意図しています。
FCIP describes the encapsulation of FC Frames in TCP segments, which in turn are encapsulated inside IP packets for transporting over an IP network. It gives no consideration to the type of FC Frame that is being encapsulated. Therefore, the FC Frame may actually contain an IP packet as described in the IP over FC specification (RFC 2625). In such a case, the data packet would have:
FCIPはTCPセグメントでFC Framesのカプセル化について説明します。(セグメントはIPネットワークの上の輸送のためにIPパケットの中で順番に要約されます)。 それは要約されているFC Frameのタイプを検討しません。 したがって、FC Frameは実際にFC仕様(RFC2625)の上のIPで説明されるようにIPパケットを含むかもしれません。 このような場合には、データ・パケットには、以下があるでしょう。
- Data Link Header
- IP Header
- TCP Header
- FCIP Header
- FC Header
- IP Header
- データはヘッダーをリンクします--IPヘッダー--TCPヘッダー--FCIPヘッダー--FCヘッダー--IPヘッダー
Note: The two IP headers would not be identical to each other. One would have information pertaining to the final destination, while the other would have information pertaining to the FCIP Entity.
以下に注意してください。 互いには、2個のIPヘッダーは同じでないでしょう。 1つには、最終的な目的地に関係する情報があるでしょうが、もう片方では、FCIP Entityに関係する情報があるでしょう。
The two documents focus on different objectives. As mentioned above, implementation of FCIP will lead to IP encapsulation within IP. While perhaps inefficient, this should not lead to issues with IP communication. One caveat: if a Fibre Channel device is encapsulating IP packets in an FC Frame (e.g., an IPFC device), and that device is communicating with a device running IP over a non-FC medium, a second IPFC device may need to act as a gateway between the two networks. This scenario is not specifically addressed by FCIP.
2通のドキュメントが異なった目的に焦点を合わせます。 以上のように、FCIPの実現はIPの中でIPカプセル化につながるでしょう。 恐らく効率が悪い間、これはIPコミュニケーションの問題に通じるべきではありません。 1つの警告: Fibre Channel装置がFC Frame(例えば、IPFC装置)でIPパケットをカプセルに入れっていて、その装置がIPをひく装置と非FC媒体を伝えているなら、2番目のIPFC装置は、2つのネットワークの間のゲートウェイとして機能する必要があるかもしれません。 このシナリオはFCIPによって明確に記述されません。
There is nothing in either of the specifications to prevent a single device from implementing both FCIP and IP-over-FC (IPFC), but this is implementation specific, and is beyond the scope of this document.
単一の装置がFCIPとIP過剰FC(IPFC)の両方を実行するのを防ぐために何も仕様のどちらかにありませんが、これは、実現特有であり、このドキュメントの範囲を超えています。
Rajagopal, et al. Standards Track [Page 58] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[58ページ]。
Appendix F - FC Frame Format
付録F--FCフレーム形式
Note: All users of the words "character" or "characters" in this section refer to 8bit/10bit link encoding wherein each 8 bit "character" within a link frame is encoded as a 10 bit "character" for link transmission. These words do not refer to ASCII, Unicode, or any other form of text characters, although octets from such characters will occur as 8 bit "characters" for this encoding. This usage is employed here for consistency with the ANSI T11 standards that specify Fibre Channel.
以下に注意してください。 このセクションの単語「キャラクタ」か「キャラクタ」のすべてのユーザがリンクフレームの中のそれぞれの8ビット「キャラクタ」がリンクトランスミッションのための10ビット「キャラクタ」としてコード化される8ビット/10ビットのリンクコード化について言及します。 これらの単語はASCIIについて言及しません、ユニコード、またはいかなる他のフォームのテキストキャラクタ、8がこのコード化のために「キャラクタ」に噛み付いたとき、そのようなキャラクタからの八重奏は起こるでしょうが。 この用法は一貫性にここでFibre Channelを指定するANSI T11規格で使われます。
The contents of this annex are informative.
この別館の内容は有益です。
All FC Frames have a standard format (see FC-FS [5]) much like LAN's 802.x protocols. However, the exact size of each FC Frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in figure 16, resulting in the minimum size FC Frame of 36 bytes and the maximum size FC Frame of 2148 bytes. Valid FC Frame lengths are always a multiple of four bytes.
すべてのFC Framesには、標準書式があります。(LANの802.xプロトコルのようにFC-FS[5])を見てください。 しかしながら、変数フィールドのサイズによって、それぞれのFC Frameの実寸は異なります。 変数フィールドのサイズは0から図にFC Frame Formatに示される2112バイト16に変化します、36バイトの最小規模FC Frameと2148バイトの最大サイズFC Frameをもたらして。 いつも有効なFC Frameの長さは4バイトの倍数です。
+------+--------+-----------+----//-------+------+------+ | SOF |Frame |Optional | Frame | CRC | EOF | | (4B) |Header |Header | Payload | (4B) | (4B) | | |(24B) |<----------------------->| | | | | | Data Field = (0-2112B) | | | +------+--------+-----------+----//-------+------+------+
+------+--------+-----------+----//-------+------+------+ | SOF|フレーム|任意| フレーム| CRC| EOF| | (4B) |ヘッダー|ヘッダー| 有効搭載量| (4B) | (4B) | | |(24B) | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| データ・フィールドは(0-2112B)と等しいです。| | | +------+--------+-----------+----//-------+------+------+
Figure 16: FC Frame Format
図16: FCフレーム形式
SOF and EOF Delimiters
SOFとEOFデリミタ
On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are
called Ordered Sets and are sent as special words constructed from
the 8B/10B comma character (K28.5) followed by three additional
8B/10B data characters making them uniquely identifiable in the
data stream.
FCリンクに、特別な単語が8B/10Bコンマから彼らをデータ・ストリームで唯一身元保証可能にしている3つの追加8B/10Bデータキャラクタによって後をつけられたキャラクタ(K28.5)を組み立てたので、フレームのStart(SOF)とフレームのEnd(EOF)をOrdered Setsと呼んで、送ります。
On an FC link, the SOF delimiter serves to identify the beginning
of an FC Frame and prepares the receiver for FC Frame reception.
The SOF contains information about the FC Frame's Class of
Service, position within a sequence, and in some cases, connection
status.
FCリンクの上では、SOFデリミタは、FC Frameの始まりを特定するのに役立って、FC Frameレセプションのために受信機を準備します。 SOFはFC FrameのService、系列の中の見解のClass、およびいくつかの場合接続形態の情報を含んでいます。
The EOF delimiter identifies the end of the FC Frame and the final
FC Frame of a sequence. In addition, it serves to force the
running disparity to negative. The EOF is used to end the
connection in connection-oriented classes of service.
EOFデリミタはFC Frameの端と系列の最終的なFC Frameを特定します。 さらに、それは、走行の不一致を否定的に強制するのに役立ちます。 EOFは、接続指向のクラスのサービスにおける接続を終わらせるのに使用されます。
Rajagopal, et al. Standards Track [Page 59] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[59ページ]。
A special EOF delimiter called EOFa (End Of Frame - Abort) is used
to terminate a partial FC Frame resulting from a malfunction in a
link facility during transmission. Since an FCIP Entity functions
like a transmission link with respect to the rest of the FC
Fabric, FCIP_DEs may use EOFa in their error recovery procedures.
EOFa(Of Frameを終わらせてください--中止になる)と呼ばれる特別なEOFデリミタは、トランスミッションの間にリンク施設に不調から生じる部分的なFC Frameを終えるのに使用されます。 FCIP EntityがFC Fabricの残りに関するトランスミッションリンクのように機能するので、FCIP_DEsは彼らのエラー回復手順でEOFaを使用するかもしれません。
It is therefore important to preserve the information conveyed by
the delimiters across the IP-based network, so that the receiving
FCIP Entity can correctly reconstruct the FC Frame in its original
SOF and EOF format before forwarding it to its ultimate FC
destination on the FC link.
したがって、IP接続を基本にしたネットワークの向こう側にデリミタによって伝えられた情報を保存するのは重要です、FCリンクの上に究極のFCの目的地にそれを送る前に受信FCIP EntityがそのオリジナルのSOFとEOF形式で正しくFC Frameを再建できるように。
When an FC Frame is encapsulated and sent over a byte-oriented
interface, the SOF and EOF delimiters are represented as sequences
of four consecutive bytes, which carry the equivalent Class of
Service and FC Frame termination information as the FC ordered
sets.
バイト指向のインタフェースの上にFC Frameを要約して、送るとき、連続した4バイトの系列としてSOFとEOFデリミタを表します。(FCがセットを注文したので、バイトはServiceとFC Frame終了情報の同等なClassを運びます)。
The representation of SOF and EOF in an encapsulation FC Frame is
described in FC Frame Encapsulation [19].
カプセル化FC FrameのSOFとEOFの表現はFC Frame Encapsulation[19]で説明されます。
Frame Header
フレームヘッダー
The FC Frame Header is transparent to the FCIP Entity. The FC
Frame Header is 24 bytes long and has several fields that are
associated with the identification and control of the payload.
Current FC Standards allow up to 3 Optional Header fields [5]:
FC Frame HeaderはFCIP Entityに透明です。 FC Frame Headerは24バイト長であり、ペイロードの識別とコントロールに関連しているいくつかの分野を持っています。 現在のFC Standardsは最大3つのOptional Header分野[5]を許容します:
- Network_Header (16-bytes)
- Association_Header (32-bytes)
- Device_Header (up to 64-bytes).
- _ヘッダーの(16バイト)(協会_ヘッダー(32バイト))の装置_ヘッダー(64バイトまでの)をネットワークでつないでください。
Frame Payload
フレーム有効搭載量
The FC Frame Payload is transparent to the FCIP Entity. An FC
application level payload is called an Information Unit at the
FC-4 Level. This is mapped into the FC Frame Payload of the FC
Frame. A large Information Unit is segmented using a structure
consisting of FC Sequences. Typically, a Sequence consists of
more than one FC Frame. FCIP does not maintain any state
information regarding the relationship of FC Frames within an FC
Sequence.
FC Frame有効搭載量はFCIP Entityに透明です。 FCアプリケーションレベルペイロードはFC-4 Levelに情報Unitと呼ばれます。 これはFC FrameのFC Frame有効搭載量に写像されます。 大きい情報Unitは、FC Sequencesから成る構造を使用することで区分されます。 通常、Sequenceは1FC Frameから成ります。 FCIPはFC Sequenceの中でFC Framesの関係の少しの州の情報も保守しません。
CRC
CRC
The FC CRC is 4 bytes long and uses the same 32-bit polynomial
used in FDDI and is specified in ANSI X3.139 Fiber Distributed
Data Interface. This CRC value is calculated over the entire FC
FC CRCは4バイト長であり、FDDIで使用される同じ32ビットの多項式を使用して、ANSI X3.139ファイバ分散データインタフェースで指定されます。 このCRC値は全体のFCの上で計算されます。
Rajagopal, et al. Standards Track [Page 60] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[60ページ]。
header and the FC payload; it does not include the SOF and EOF
delimiters.
ヘッダーとFCペイロード。 それはSOFとEOFデリミタを含んでいません。
Note: When FC Frames are encapsulated into FCIP Frames, the FC
Frame CRC is untouched by the FCIP Entity.
以下に注意してください。 FC FramesがFCIP Framesに要約されるとき、FC Frame CRCはFCIP Entityで触れません。
Appendix G - FC Encapsulation Format
付録G--FCカプセル化形式
This annex contains a reproduction of the FC Encapsulation Format [19] as it applies to FCIP Frames that encapsulate FC Frames. The information in this annex is not intended to represent the FCIP Special Frame (FSF) that is described in section 7.
[19] それがFC Framesを要約するFCIP Framesに適用されるとき、この別館はFC Encapsulation Formatの再生産を含んでいます。 この別館の情報がセクション7で説明されるFCIP Special Frame(FSF)を表すことを意図しません。
The information in this annex was correct as of the time this specification was approved. The information in this annex is informative only.
この別館の情報はこの仕様が承認された時点で、正しかったです。 別館が有益であるというこれの情報専用。
If there are any differences between the information here and the FC Encapsulation Format specification [19], the FC Encapsulation Format specification takes precedence.
ここの情報とFC Encapsulation Format仕様[19]の間には、何か違いがあれば、FC Encapsulation Format仕様は優先します。
If there are any differences between the information here and the contents of section 5.6.1, then the contents of section 5.6.1 take precedence.
ここの情報とセクション5.6.1のコンテンツの間には、何か違いがあれば、セクション5.6.1の内容は優先します。
Figure 17 applies the requirements stated in section 5.6.1 and in the FC Encapsulation Frame format resulting in a summary of the FC Frame format. Where FCIP requires specific values, those values are shown in hexadecimal in parentheses. Detailed requirements for the FCIP usage of the FC Encapsulation Format are in section 5.6.1.
図17はFC Frame形式の概要をもたらすセクション5.6.1とFC Encapsulation Frame形式で述べられた要件を当てはまります。 FCIPが特定の値を必要とするところでは、それらの値は括弧の16進で示されます。 セクション5.6.1にはFC Encapsulation FormatのFCIP使用法のための詳細な要件があります。
Rajagopal, et al. Standards Track [Page 61] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[61ページ]。
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 |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| (0x00) | (0x00) | (0xFF) | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0x00) | | (0x3F) | |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+---------------+---------------+---------------+---------------+
7| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
8| |
+----- FC Frame content (see appendix F) -----+
| |
+---------------+---------------+---------------+---------------+
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 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| プロトコル#| バージョン| -プロトコル#| -バージョン| | (0×01) | (0×01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| プロトコル#| バージョン| -プロトコル#| -バージョン| | (0×01) | (0×01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags| 予約されます。| -pFlags| -予約されます。| | (0×00) | (0×00) | (0xFF) | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| 旗| フレームの長さ| -旗| -フレームの長さ| | (0×00) | | (0x3F) | | +-----------+-------------------+-----------+-------------------+ 4| タイムスタンプ[整数]| +---------------------------------------------------------------+ 5| タイムスタンプ[断片]| +---------------------------------------------------------------+ 6| CRC(FCIPでは、予約されます)| | (0×00 00-00-00) | +---------------+---------------+---------------+---------------+ 7| SOF| SOF| -SOF| -SOF| +---------------+---------------+---------------+---------------+ 8| | +----- FC Frame内容(付録Fを見ます)-----+ | | +---------------+---------------+---------------+---------------+ n| EOF| EOF| -EOF| -EOF| +---------------+---------------+---------------+---------------+
Figure 17: FCIP Frame Format
図17: FCIPフレーム形式
The names of fields are generally descriptive on their contents and the FC Encapsulation Format specification [19] is referenced for details. Field names preceded by a minus sign are ones complement values of the named field.
一般に、分野の名前はそれらのコンテンツで描写的です、そして、FC Encapsulation Format仕様[19]は詳細のために参照をつけられます。 マイナス記号が先行したフィールド名は命名された分野のもの補数の値です。
Note: Figure 17 does not represent the FSF that is described in section 7.
以下に注意してください。 図17はセクション7で説明されるFSFを表しません。
Rajagopal, et al. Standards Track [Page 62] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[62ページ]。
Appendix H - FCIP Requirements on an FC Entity
付録H--FC実体に関するFCIP要件
The contents of this annex are informative for FCIP but might be considered normative on FC-BB-2.
この別館の内容は、FCIPに有益ですが、FC掲示板2で規範的であると考えられるかもしれません。
The capabilities that FCIP requires of an FC Entity include:
FCIPが必要とするFC Entityの能力は:
1) The FC Entity must deliver FC Frames to the correct FCIP Data
Engine (in the correct FCIP Link Endpoint).
1) FC Entityは正しいFCIP Data Engine(正しいFCIP Link Endpointの)にFC Framesを渡さなければなりません。
2) Each FC Frame delivered to an FCIP_DE must be accompanied by a
time value synchronized with the clock maintained by the FC Entity
at the other end of the FCIP Link (see section 6). If a
synchronized time value is not available, a value of zero must
accompany the FC Frame.
2) FCIP Linkのもう一方の端でFC Entityによって維持される時計と同期する時間的価値でFCIP_DEに届けられた各FC Frameに同伴しなければなりません(セクション6を見てください)。 連動している時間的価値が利用可能でないなら、ゼロの値はFC Frameに同伴しなければなりません。
3) When FC Frames exit FCIP Data Engine(s) via the FC Frame
Transmitter Portal(s), the FC Entity should forward them to the FC
Fabric. However, before forwarding an FC Frame, the FC Entity
must compute the end-to-end transit time for the FC Frame using
the time value supplied by the FCIP_DE (taken from the FCIP
header) and a synchronized time value (see section 6). If the
end-to-end transit time exceeds the requirements of the FC Fabric,
the FC Entity is responsible for discarding the FC Frame.
3) FC FramesがFC Frame Transmitter Portal(s)を通してFCIP Data Engine(s)を出るとき、FC Entityは彼らをFC Fabricに送るはずです。 しかしながら、FC Frameを進める前に、FC Entityは、FCIP_DE(FCIPヘッダーから、取る)によって供給された時間的価値と連動している時間的価値を使用することでFC Frameのためのトランジット時間の終わりから終わりを計算しなければなりません(セクション6を見てください)。 トランジット時間の終わりから終わりがFC Fabricの要件を超えているなら、FC EntityはFC Frameを捨てるのに責任があります。
4) The only delivery ordering guarantee provided by FCIP is correctly
ordered delivery of FC Frames between a pair of FCIP Data Engines.
FCIP expects the FC Entity to implement all other FC Frame
delivery ordering requirements.
4) 1組のFCIP Data Enginesの間のFC Framesの配送は正しくFCIPが保証を提供するよう命令する唯一の配送に命令されます。 FCIPは、FC Entityが要件を命令する他のすべてのFC Frame配送を実行すると予想します。
5) When a TCP connect request is received and that request would add
a new TCP Connection to an existing FCIP_LEP, the FC Entity must
authenticate the source of the TCP connect request before use of
the new TCP connection is allowed.
5) TCPが接続するとき、要求は受信されています、そして、新しいTCP接続の使用が許される前に要求が既存のFCIP_LEPに新しいTCP Connectionを加えて、FC EntityがTCPの源を認証しなければならないのが要求を接続します。
6) The FC Entity may participate in determining allowed TCP
Connections, TCP Connection parameters, quality of service usage,
and security usage by modifying interactions with the FCIP Entity
that are modelled as a "shared" database in section 8.1.1.
6) FC EntityはTCPコネクションズ、TCP Connectionパラメタ、サービスの質用法、およびセキュリティ用法がセクション8.1.1における「共有された」データベースとしてモデル化されるFCIP Entityとの相互作用を変更することによって許容された決定に参加するかもしれません。
7) The FC Entity may require the FCIP Entity to perform TCP close
requests.
7) FC Entityは、FCIP EntityがTCPの厳密な要求を実行するのを必要とするかもしれません。
8) The FC Entity may recover from connection failures.
8) FC Entityは接続失敗から回復するかもしれません。
9) The FC Entity must recover from events that the FCIP Entity cannot
handle, such as:
9) FC Entityは以下のようにFCIP Entityが扱うことができない出来事から回復しなければなりません。
Rajagopal, et al. Standards Track [Page 63] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[63ページ]。
a) loss of synchronization with FCIP Frame headers from the
Encapsulated Frame Receiver Portal requiring resetting the TCP
Connection; and
a) Encapsulated Frame Receiver PortalからのTCP Connectionをリセットするのを必要とするFCIP Frameヘッダーとの同期の損失。 そして
b) recovering from FCIP Frames that are discarded as a result of
synchronization problems (see section 5.6.2.2 and section
5.6.2.3).
セクション5.6.2の.2と部5.6を見てください。同期問題の結果、捨てられるFCIP Framesから回復するb)、(.2 .3)。
10) The FC Entity must work cooperatively with the FCIP Entity to
manage flow control problems in either the IP Network or FC
Fabric.
10) FC Entityは、IP NetworkかFC Fabricのどちらかのフロー制御問題を管理するためにFCIP Entityと共に協力して働かなければなりません。
11) The FC Entity may test for failed TCP Connections.
11) FC Entityは失敗したTCPコネクションズがないかどうかテストするかもしれません。
Note that the Fibre Channel standards must be consulted for a
complete understanding of the requirements placed on an FC
Entity.
FC Entityに置かれた要件の完全な理解のためにFibre Channel規格に相談しなければならないことに注意してください。
Table 2 shows the explicit interactions between the FCIP Entity
and the FC Entity.
テーブル2はFCIP EntityとFC Entityとの明白な相互作用を示しています。
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | 5.6 | FC Frame ready | | Provide FC | | FCIP Data | for IP transfer | | Frame and | | Engine | | | time stamp at | | | | | FC Frame | | | | | Receiver Portal | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+ | | | そして情報/パラメタが終わった。| | | | 指示| | 参照| +-----------------+-----------------+ | セクション| 状態| FCIP実体--->| <--FC実体| +-------------+-----------------+-----------------+-----------------+ | 5.6 | FC Frame準備ができています。| | FCを提供してください。| | FCIPデータ| IP転送のために| | そしてフレーム。| | エンジン| | | スタンプを調節します。| | | | | FCフレーム| | | | | 受信機入り口| +-------------+-----------------+-----------------+-----------------+ | WWNは世界的な名前と等しいです。| +-------------------------------------------------------------------+ | 続けられています。| +-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 1 of 5)
テーブル2: FC/FCIP Entity組相互作用(5の第1部)
Rajagopal, et al. Standards Track [Page 64] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[64ページ]。
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 5.6 | FCIP Frame | Provide FC | | | FCIP Data | received from | Frame and | | | Engine | IP Network | time stamp at | | | | | FC Frame Trans- | | | | | mitter Portal | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.2 | FCIP_DE | Inform FC | | | Errors | discards bytes | Entity that | | | in FCIP | delivered | bytes have been | | | Headers and | through | discarded with | | | Discarding | Encapsulated | reason | | | FCIP Frames | Frame Receiver | | | | | Portal | | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.3 | FCIP Entity | Inform FC | | | Synchron- | closes TCP | Entity that TCP | | | ization | Connection due | Connection has | | | Failures | to synchron- | been closed | | | | ization failure | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.3 | Receipt of the | Inform FC | | | Connection | echoed FSF | Entity that TCP | | | Setup | takes too long | Connection has | | | Following a | or the FSF | been closed | | | Successful | contents have | with reason | | | TCP Connect | changed | for closure | | | Request | | | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+ | | | そして情報/パラメタが終わった。| | | | 指示| | 参照| +-----------------+-----------------+ | セクション| 状態| FCIP実体--->| <--FC実体| +-------------+-----------------+-----------------+-----------------+ | 続けられています。| +-------------+-----------------+-----------------+-----------------+ | 5.6 | FCIPフレーム| FCを提供してください。| | | FCIPデータ| 受け取られている| そしてフレーム。| | | エンジン| IPネットワーク| スタンプを調節します。| | | | | FCが縁どっている、移-| | | | | mitter Portal| | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.2 | FCIP_DE| FCに知らせてください。| | | 誤り| バイトを捨てます。| 実体、それ| | | FCIPで| 配送します。| バイトがありました。| | | そしてヘッダー。| 突き抜ける| 捨てられます。| | | 捨てます。| 要約されます。| 理由| | | FCIPフレーム| フレーム受信機| | | | | 入り口| | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.3 | FCIP実体| FCに知らせてください。| | | Synchron| TCPを閉じます。| 実体はそのTCPです。| | | ization| 接続支払われるべきもの| 接続はそうしました。| | | 失敗| synchronに| 閉じられます。| | | | izationの故障| 理由で| | | | | 閉鎖のために| | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.3 | 領収書| FCに知らせてください。| | | 接続| 反響しているFSF| 実体はそのTCPです。| | | セットアップ| また、時間がかかります。| 接続はそうしました。| | | aに続きます。| または、FSF| 閉じられます。| | | うまくいく| 内容はそうしました。| 理由で| | | TCPは接続します。| 変えます。| 閉鎖のために| | | 要求| | | | +-------------+-----------------+-----------------+-----------------+ | WWNは世界的な名前と等しいです。| +-------------------------------------------------------------------+ | 続けられています。| +-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 2 of 5)
テーブル2: FC/FCIP Entity組相互作用(5の第2部)
Rajagopal, et al. Standards Track [Page 65] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[65ページ]。
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.1 | New TCP | Inform FC | | | Non-Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on "shared" | FCIP_LEP and | | | Connections | database | new FCIP_DE | | | | information | along with | | | | | Destination FC | | | | | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.2 | New TCP | Inform FC | | | Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on SLP service | FCIP_LEP and | | | Connections | advertisement | new FCIP_DE | | | | and "shared" | along with | | | | database | Destination FC | | | | information | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+ | | | そして情報/パラメタが終わった。| | | | 指示| | 参照| +-----------------+-----------------+ | セクション| 状態| FCIP実体--->| <--FC実体| +-------------+-----------------+-----------------+-----------------+ | 続けられています。| +-------------+-----------------+-----------------+-----------------+ | 8.1.2.1 | 新しいTCP| FCに知らせてください。| | | 非ダイナミックです。| 接続| 実体| | | 創造| ベースで、作成されます。| 新しいか、または既存です。| | | 新しいTCP| 「共有」に関して| そしてFCIP_LEP。| | | コネクションズ| データベース| 新しいFCIP_DE| | | | 情報| along with| | | | | 目的地FC| | | | | 織物実体| | | | | WWN、接続| | | | | 用法は弛みます。| | | | | 接続| | | | | そして用法コード。| | | | | 接続| | | | | 一回だけ| | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.2 | 新しいTCP| FCに知らせてください。| | | 動力| 接続| 実体| | | 創造| ベースで、作成されます。| 新しいか、または既存です。| | | 新しいTCP| SLPサービスに関して| そしてFCIP_LEP。| | | コネクションズ| 広告| 新しいFCIP_DE| | | | そして、「共有にされる」| along with| | | | データベース| 目的地FC| | | | 情報| 織物実体| | | | | WWN、接続| | | | | 用法は弛みます。| | | | | 接続| | | | | そして用法コード。| | | | | 接続| | | | | 一回だけ| | +-------------+-----------------+-----------------+-----------------+ | WWNは世界的な名前と等しいです。| +-------------------------------------------------------------------+ | 続けられています。| +-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 3 of 5)
テーブル2: FC/FCIP Entity組相互作用(5の一部3)
Rajagopal, et al. Standards Track [Page 66] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[66ページ]。
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | New TCP | Inform FC | | | Processing | Connection | Entity of | | | Incoming | created based | new or existing | | | TCP Connect | on incoming TCP | FCIP_LEP and | | | Requests | Connect request | new FCIP_DE | | | | and "shared" | along with | | | | database | Source FC | | | | information | Fabric Entity | | | | | WWN, Source | | | | | FC/FCIP Entity | | | | | Identifier, | | | | | Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | TCP Connect | Request FC | Yes or No | | Processing | Request wants | Entity to | answer about | | Incoming | to add a new | authenticate | whether the | | TCP Connect | TCP Connection | the source of | source of the | | Requests | to an existing | the TCP Connect | TCP Connect | | | FCIP_LEP | Request | Request can be | | | | | authenticated | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | Receipt of the | Inform FC | | | Processing | FSF takes too | Entity that TCP | | | Incoming | long or | Connection has | | | TCP Connect | duplicate | been closed | | | Requests | Connection | with reason | | | | Nonce value | for closure | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+ | | | そして情報/パラメタが終わった。| | | | 指示| | 参照| +-----------------+-----------------+ | セクション| 状態| FCIP実体--->| <--FC実体| +-------------+-----------------+-----------------+-----------------+ | 続けられています。| +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | 新しいTCP| FCに知らせてください。| | | 処理| 接続| 実体| | | 入来| ベースで、作成されます。| 新しいか、または既存です。| | | TCPは接続します。| 入って来るTCPに関して| そしてFCIP_LEP。| | | 要求| 要求を接続してください。| 新しいFCIP_DE| | | | そして、「共有にされる」| along with| | | | データベース| ソースFC| | | | 情報| 織物実体| | | | | WWN、ソース| | | | | FC/FCIP実体| | | | | 識別子| | | | | 接続| | | | | 用法は弛みます。| | | | | 接続| | | | | そして用法コード。| | | | | 接続| | | | | 一回だけ| | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | TCPは接続します。| FCを要求してください。| 諾否| | 処理| 必需品を要求してください。| 実体| 答えます。| | 入来| 新しい状態でaを加えるために| 認証します。| the| | TCPは接続します。| TCP接続| ソース| ソース| | 要求| 存在に| TCPは接続します。| TCPは接続します。| | | FCIP_LEP| 要求| 要求はそうであることができます。| | | | | 認証されます。| +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | 領収書| FCに知らせてください。| | | 処理| また、FSFは取ります。| 実体はそのTCPです。| | | 入来| または長さ。| 接続はそうしました。| | | TCPは接続します。| 写し| 閉じられます。| | | 要求| 接続| 理由で| | | | 一回だけの値| 閉鎖のために| | +-------------+-----------------+-----------------+-----------------+ | WWNは世界的な名前と等しいです。| +-------------------------------------------------------------------+ | 続けられています。| +-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 4 of 5)
テーブル2: FC/FCIP Entity組相互作用(5の一部4)
Rajagopal, et al. Standards Track [Page 67] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[67ページ]。
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | concluded | +-------------+-----------------+-----------------+-----------------+ | 8.2 | FC Entity | Acknowledgement | Identification | | Closing TCP | determines | of TCP | of the FCIP_DE | | Connections | that a TCP | Connection | whose TCP | | | Connection | closure | Connection | | | needs to be | | needs to be | | | closed | | closed | +-------------+-----------------+-----------------+-----------------+ | 8.4 | Discovery that | Inform FC | | | TCP | TCP connectiv- | Entity that TCP | | | Connection | ity has been | Connection has | | | Considera- | lost | been closed | | | tions | | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | 9.4.1 | IKE phase 1 | Inform FC | | | FCIP | failed, result- | Entity that TCP | | | Link | ing in termin- | Connection can | | | Initializ- | ation of link | not be opened | | | ation Steps | initialization | with reason for | | | | | failure | | +-------------+-----------------+-----------------+-----------------+ | 9.4.3 | Excessive | Inform FC | | | Handling | numbers of | Entity that TCP | | | data | dropped | Connection has | | | integrity | datagrams | been closed | | | and confi- | detected and | with reason | | | dentiality | TCP Connection | for closure | | | violations | closed | | | +-------------+-----------------+-----------------+-----------------+ | RFC 3723 | TCP Connection | Inform FC | | | | closed due to | Entity that TCP | | | Handling SA | SA parameter | Connection has | | | parameter | mismatch | been closed | | | mismatches | problems | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+ | | | そして情報/パラメタが終わった。| | | | 指示| | 参照| +-----------------+-----------------+ | セクション| 状態| FCIP実体--->| <--FC実体| +-------------+-----------------+-----------------+-----------------+ | 結論を下します。| +-------------+-----------------+-----------------+-----------------+ | 8.2 | FC実体| 承認| 識別| | TCPを閉じます。| 決定します。| TCPについて| FCIP_DEについて| | コネクションズ| それはTCPです。| 接続| TCP| | | 接続| 閉鎖| 接続| | | 必要です。| | 必要です。| | | 閉じられます。| | 閉じられます。| +-------------+-----------------+-----------------+-----------------+ | 8.4 | 発見、それ| FCに知らせてください。| | | TCP| TCP connectiv| 実体はそのTCPです。| | | 接続| ityがありました。| 接続はそうしました。| | | Considera| 失われています。| 閉じられます。| | | tions| | 理由で| | | | | 閉鎖のために| | +-------------+-----------------+-----------------+-----------------+ | 9.4.1 | IKEフェーズ1| FCに知らせてください。| | | FCIP| 失敗されていて、なってください。| 実体はそのTCPです。| | | リンク| terminのing| 接続はそうすることができます。| | | Initializ| リンクのation| 開かれないでください。| | | ation Steps| 初期化| 推論します。| | | | | 失敗| | +-------------+-----------------+-----------------+-----------------+ | 9.4.3 | 過度である| FCに知らせてください。| | | 取り扱い| 数| 実体はそのTCPです。| | | データ| 落とされます。| 接続はそうしました。| | | 保全| データグラム| 閉じられます。| | | そして、confi| そして検出。| 理由で| | | dentiality| TCP接続| 閉鎖のために| | | 違反| 閉じられます。| | | +-------------+-----------------+-----------------+-----------------+ | RFC3723| TCP接続| FCに知らせてください。| | | | 当然の状態で、閉じられます。| 実体はそのTCPです。| | | 取り扱いSA| SAパラメタ| 接続はそうしました。| | | パラメタ| ミスマッチ| 閉じられます。| | | ミスマッチ| 問題| 理由で| | | | | 閉鎖のために| | +-------------+-----------------+-----------------+-----------------+ | WWNは世界的な名前と等しいです。| +-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 5 of 5)
テーブル2: FC/FCIP Entity組相互作用(5の一部5)
Rajagopal, et al. Standards Track [Page 68] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[68ページ]。
Editors and Contributors Acknowledgements
エディターズと貢献者承認
During the development of this specification, Murali Rajagopal, Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively as editors. Raj Bhagwat contributed substantially to the initial basic FCIP concepts.
この仕様の開発の間、Murali Rajagopal、エリザベス・ロドリゲス、Vi Chau、およびラルフ・ウェーバーはエディタとして連続して勤めました。 主権Bhagwatは実質的に初期の基本のFCIP概念に貢献しました。
Venkat Rangan contributed the Security section and continues to coordinate security issues with the ips Working Group and IETF.
ヴェンカトRanganは、Security部を寄付して、ips作業部会とIETFの安全保障問題を調整し続けています。
Andy Helland contributed a substantial revision of Performance section, aligning it with TCP/IP QoS concepts.
TCP/IP QoS概念にそれを一直線にして、アンディHellandはパフォーマンス部のかなりの改正を寄付しました。
Dave Peterson contributed the dynamic discovery section and edits to RFC 3822.
デーヴ・ピーターソンはダイナミックな発見部と編集をRFC3822に寄付しました。
Anil Rijhsinghani contributed material related to the FCIP MIB and edits the FCIP MIB document.
コマツナギRijhsinghaniはFCIP MIBに関連する材料を寄付して、FCIP MIBドキュメントを編集します。
Bob Snively contributed material related to error detection and recovery including the bulk of the synchronization recovery example annex.
ボブSnivelyは誤り検出に関連する材料と同期回復例の別館の嵩を含む回復を寄付しました。
Lawrence J. Lamers contributed numerous ideas focused on keeping FCIP compatible with B_Port devices.
ローレンスJ.LamersはB_Port装置があるFCIP互換性があった状態で保つのに集中している多数の考えを寄付しました。
Milan Merhar contributed several of the FCIP conceptual modifications necessary to support NATs.
ミラノMerharはNATsを支持するのに必要ないくつかのFCIP概念的な変更を寄付しました。
Don Fraser contributed material related to link failure detection and reporting.
ドン・フレーザはリンク失敗検出と報告に関連する材料を寄付しました。
Bill Krieg contributed a restructuring of the TCP Connection setup sections that made them more linear with respect to time and more readable.
ビル・クリーグはそれらを時間に関して、より直線的でより読み込み可能にしたTCP Connectionセットアップ部の企業再構築を寄付しました。
Several T11 leaders supported this effort and advised the editors of this specification regarding coordination with T11 documents and projects. These T11 leaders are: Jim Nelson (Framing and Signaling), Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone), Steve Wilson (Switch Fabric), and Michael O'Donnell (Security Protocols).
数人のT11リーダーが、この努力を支持して、T11ドキュメントとプロジェクトと共にコーディネートに関するこの仕様をエディタに知らせました。 これらのT11リーダーは以下の通りです。 ジム・ネルソン(縁どっていて、合図する)、ニール・ワナメイカー(縁どっていて、合図する)、クレイグ・カールソン(一般的なサービス)、ケン平田(スイッチ織物)、Murali Rajagopal(背骨)、スティーヴ・ウィルソン(スイッチ織物)、およびマイケル・オドネル(セキュリティプロトコル)。
Rajagopal, et al. Standards Track [Page 69] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[69ページ]。
Editors and Contributors Addresses
エディターズと貢献者アドレス
Neil Wanamaker Akara 10624 Icarus Court Austin, TX 78726 USA
ニールワナメイカーAkara10624イカロス・法廷テキサス78726オースチン(米国)
Phone: +1 512 257 7633 Fax: +1 512 257 7877 EMail: nwanamaker@akara.com
以下に電話をしてください。 +1 512 257、7633Fax: +1 7877年の512 257メール: nwanamaker@akara.com
Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
Brocade Suite102PMB178 18484プレストン・ロード・テキサス75252ダラス(米国)を代表するラルフ・ウェーバー・ENDLテキサス
Phone: +1 214 912 1373 EMail: roweber@ieee.org
以下に電話をしてください。 +1 1373年の214 912メール: roweber@ieee.org
Elizabeth G. Rodriguez Dot Hill Systems Corp. 6305 El Camino Real Carlsbad, CA 92009 USA
エリザベスG.ロドリゲスドットヒルSystems社6305のエル・カミーノ本当のカールスバッド(カリフォルニア)92009米国
Phone: +1 760 431 4435 EMail: elizabeth.rodriguez@dothill.com
以下に電話をしてください。 +1 4435年の760 431メール: elizabeth.rodriguez@dothill.com
Steve Wilson Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA. 95110 USA
スティーヴ・ウィルソン錦のComm。 1745年のシステムInc.技術はサンノゼ(カリフォルニア)を運転します。 95110 米国
Phone: +1 408 333 8128 EMail: swilson@brocade.com
以下に電話をしてください。 +1 8128年の408 333メール: swilson@brocade.com
Rajagopal, et al. Standards Track [Page 70] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[70ページ]。
Bob Snively Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA 95110 USA
ボブSnivelyはCommを紋織りにします。 1745年のシステムInc.技術はサンノゼ、カリフォルニア95110米国を運転します。
Phone: +1 408 303 8135 EMail: rsnively@brocade.com
以下に電話をしてください。 +1 8135年の408 303メール: rsnively@brocade.com
David Peterson Cisco Systems - SRBU 6450 Wedgwood Road Maple Grove, MN 55311 USA
デヴィッドピーターソンシスコシステムズ--SRBU6450ウェッジウッド道路メープル・グローヴ、MN55311米国
Phone: +1 763 398 1007 Cell: +1 612 802 3299 EMail: dap@cisco.com
以下に電話をしてください。 +1 1007年の763 398セル: +1 3299年の612 802メール: dap@cisco.com
Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd., Bldg. 5 Colorado Springs, CO 80919 USA
ドナルドR.フレーザヒューレット・パッカード301Rockrimmon Blvd.、ビルディング 5 コロラド・スプリングス、CO80919米国
Phone: +1 719 548 3272 EMail: Don.Fraser@HP.com
以下に電話をしてください。 +1 3272年の719 548メール: Don.Fraser@HP.com
R. Andy Helland LightSand Communications, Inc. 375 Los Coches Street Milpitas, CA 95035 USA
R.アンディHelland LightSand Communications Inc.375ロスCoches通りミルピタス(カリフォルニア)95035米国
Phone: +1 408 404 3119 Fax: +1 408 941 2166 EMail: andyh@lightsand.com
以下に電話をしてください。 +1 408 404、3119Fax: +1 2166年の408 941メール: andyh@lightsand.com
Raj Bhagwat LightSand Communications, Inc. 24411 Ridge Route Dr. Suite 135 Laguna Hills, CA 92653 USA
Inc.24411が畝を立てさせる主権Bhagwat LightSandコミュニケーションはSuiteラグナHillsカリフォルニア92653博士135(米国)を発送します。
Phone: +1 949 837 1733 x104 EMail: rajb@lightsand.com
以下に電話をしてください。 +1 949 837、1733x104 EMail: rajb@lightsand.com
Rajagopal, et al. Standards Track [Page 71] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[71ページ]。
Bill Krieg Lucent Technologies 200 Lucent Lane Cary, NC 27511 USA
ビルクリーグルーセントテクノロジーズ200の透明なLane NC27511ケーリー(米国)
Phone: +1 919 463 4020 Fax: +1 919 463 4041 EMail: bkrieg@lucent.com
以下に電話をしてください。 +1 919 463、4020Fax: +1 4041年の919 463メール: bkrieg@lucent.com
Michael E. O'Donnell McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
マイケルE.オドネルMcDATA社310のInterlockenパークウェイのCO80021ブルームフィールド(米国)
Phone: +1 303 460 4142 Fax: +1 303 465 4996 EMail: modonnell@mcdata.com
以下に電話をしてください。 +1 303 460、4142Fax: +1 4996年の303 465メール: modonnell@mcdata.com
Anil Rijhsinghani McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
コマツナギRijhsinghani McDATA社310のInterlockenパークウェイのCO80021ブルームフィールド(米国)
Phone: +1 508 870 6593 EMail: anil.rijhsinghani@mcdata.com
以下に電話をしてください。 +1 6593年の508 870メール: anil.rijhsinghani@mcdata.com
Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA
ミラノJ.Merhar43Nagog公園Pirusはアクトン、MA01720米国をネットワークでつなぎます。
Phone: +1 978 206 9124 EMail: Milan@pirus.com
以下に電話をしてください。 +1 9124年の978 206メール: Milan@pirus.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
クレイグW.カールソンQLogic社6321のバリードライブエデン大草原、MN55346米国
Phone: +1 952 932 4064 EMail: craig.carlson@qlogic.com
以下に電話をしてください。 +1 4064年の952 932メール: craig.carlson@qlogic.com
Rajagopal, et al. Standards Track [Page 72] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[72ページ]。
Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 USA
ヴェンカトRangan Rhapsodyは株式会社3450W.ウォレンAveをネットワークでつなぎます。 フレモント、カリフォルニア94538米国
Phone: +1 510 743 3018 Fax: +1 510 687 0136 EMail: venkat@rhapsodynetworks.com
以下に電話をしてください。 +1 510 743、3018Fax: +1 0136年の510 687メール: venkat@rhapsodynetworks.com
Lawrence J. Lamers SAN Valley Systems, Inc. 6320 San Ignacio Ave. San Jose, CA 95119-1209 USA
ローレンスJ.Lamers SANバレーシステムInc.6320サンイグナシオAve。 サンノゼ、カリフォルニア95119-1209米国
Phone: +1 408 234 0071 EMail: ljlamers@ieee.org
以下に電話をしてください。 +1 0071年の408 234メール: ljlamers@ieee.org
Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine,CA 92619 USA
Murali Rajagopal Broadcom社16215のオールトンParkwayカリフォルニア92619アーバイン(米国)
Phone: +1 949 450 8700 EMail: muralir@broadcom.com
以下に電話をしてください。 +1 8700年の949 450メール: muralir@broadcom.com
Ken Hirata Vixel Corporation 15245 Alton Parkway, Suite 100 Irvine, CA 92618 USA
オールトンパークウェイ、ケン平田Vixel社15245のSuite100カリフォルニア92618アーバイン(米国)
Phone: +1 949 788 6368 Fax: +1 949 753 9500 EMail: ken.hirata@vixel.com
以下に電話をしてください。 +1 949 788、6368Fax: +1 9500年の949 753メール: ken.hirata@vixel.com
Vi Chau USA Email: vchau1@cox.net
vi Chau米国メール: vchau1@cox.net
Rajagopal, et al. Standards Track [Page 73] RFC 3821 FCIP July 2004
Rajagopal、他 規格はFCIP2004年7月にRFC3821を追跡します[73ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rajagopal, et al. Standards Track [Page 74]
Rajagopal、他 標準化過程[74ページ]
一覧
スポンサーリンク
