home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / iscsiprj.zip / draft-ietf-ips-fcovertcpip-10.txt < prev    next >
Text File  |  2002-06-02  |  164KB  |  3,686 lines
  1.  
  2.  
  3.  
  4.  
  5. IPS Working Group                                           M. Rajagopal
  6. INTERNET-DRAFT                                     Technical Coordinator
  7. <draft-ietf-ips-fcovertcpip-10.txt>
  8. (Expires November, 2002)                                    E. Rodriguez
  9. Category: standards-track                                   ips Co-Chair
  10.  
  11.                                                                 R. Weber
  12.                                                                   Editor
  13.  
  14.  
  15.                     Fibre Channel Over TCP/IP (FCIP)
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft and is in full conformance with
  20.    all provisions of Section 10 of RFC 2026 [1].
  21.  
  22.    Internet-Drafts are working documents of the Internet Engineering
  23.    Task Force (IETF), its areas, and its working groups. Note that
  24.    other groups may also distribute working documents as Internet-Drafts.
  25.  
  26.    Internet-Drafts are draft documents valid for a maximum of six
  27.    months and may be updated, replaced, or obsoleted by other documents
  28.    at any time. It is inappropriate to use Internet-Drafts as Reference
  29.    material or to cite them other than as "work in progress".
  30.  
  31.    The list of current Internet-Drafts can be accessed at 
  32.    http://www.ietf.org/ietf/lid-abstracts.txt
  33.  
  34.    The list of Internet-Draft Shadow Directories can be accessed at 
  35.    http://www.ietf.org/shadow.html
  36.  
  37. Abstract
  38.  
  39.    Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the
  40.    interconnection of islands of Fibre Channel storage area networks
  41.    over IP-based networks to form a unified storage area network in a
  42.    single Fibre Channel fabric. FCIP relies on IP-based network
  43.    services to provide the connectivity between the storage area
  44.    network islands over local area networks, metropolitan area
  45.    networks, or wide area networks.
  46.  
  47. Conventions used in this document
  48.  
  49.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  50.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  51.    document are to be interpreted as described in RFC 2119 [2].
  52.  
  53.  
  54.  
  55. Rajagopal, et al.               Standards Track                 [Page 1]
  56.  
  57. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  58.  
  59.  
  60. Table Of Contents
  61.  
  62.    1. Editors and Contributors . . . . . . . . . . . . . . . . . . . . 3
  63.    2. Purpose, Motivation and Objectives . . . . . . . . . . . . . . . 4
  64.    3. Relationship to Fibre Channel Standards  . . . . . . . . . . . . 6
  65.    3.1 Relevant Fibre Channel Standards  . . . . . . . . . . . . . . . 6
  66.    3.2 This Specification and Fibre Channel Standards  . . . . . . . . 6
  67.    4. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  68.    5. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . . 8
  69.    6. The FCIP Model  . . . . . . . . . . . . . . . . . . . . . . . . 10
  70.    6.1 FCIP Protocol Model  . . . . . . . . . . . . . . . . . . . . . 10
  71.    6.2 FCIP Link  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  72.    6.3 FC Entity  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  73.    6.4 FCIP Entity  . . . . . . . . . . . . . . . . . . . . . . . . . 12
  74.    6.5 FCIP Link Endpoint (FCIP_LEP)  . . . . . . . . . . . . . . . . 13
  75.    6.6 FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . . . . 14
  76.    6.6.1 FCIP Encapsulation of FC Frames  . . . . . . . . . . . . . . 16
  77.    6.6.2 FCIP Data Engine Error Detection and Recovery  . . . . . . . 19
  78.    6.6.2.1 TCP Assistance With Error Detection and Recovery . . . . . 19
  79.    6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames  . . . . 19
  80.    6.6.2.3 Synchronization Failures . . . . . . . . . . . . . . . . . 20
  81.    7. Checking FC Frame Transit Times in the IP Network . . . . . . . 21
  82.    8. The FCIP Special Frame (FSF)  . . . . . . . . . . . . . . . . . 22
  83.    8.1 FCIP Special Frame Format  . . . . . . . . . . . . . . . . . . 22
  84.    8.2 Overview of FSF Usage in Connection Establishment  . . . . . . 25
  85.    9. TCP Connection Management . . . . . . . . . . . . . . . . . . . 27
  86.    9.1 TCP Connection Establishment . . . . . . . . . . . . . . . . . 27
  87.    9.1.1 Connection Establishment Model . . . . . . . . . . . . . . . 27
  88.    9.1.2 Creating New TCP Connections . . . . . . . . . . . . . . . . 28
  89.    9.1.2.1 Non-Dynamic Creation of New TCP Connections  . . . . . . . 28
  90.    9.1.2.2 Dynamic Creation of New TCP Connections  . . . . . . . . . 29
  91.    9.1.2.3 Connection Setup After a Successful TCP Connect Request .  30
  92.    9.1.3 Processing Incoming TCP Connect Requests . . . . . . . . . . 31
  93.    9.1.4 Simultaneous Connection Establishment  . . . . . . . . . . . 35
  94.    9.2 Closing TCP Connections  . . . . . . . . . . . . . . . . . . . 35
  95.    9.3 TCP Connection Parameters  . . . . . . . . . . . . . . . . . . 35
  96.    9.3.1 TCP Selective Acknowledgement Option . . . . . . . . . . . . 35
  97.    9.3.2 TCP Window Scale Option  . . . . . . . . . . . . . . . . . . 36
  98.    9.3.3 Protection against sequence number wrap  . . . . . . . . . . 36
  99.    9.3.4 TCP_NODELAY Option . . . . . . . . . . . . . . . . . . . . . 36
  100.    9.4 TCP Connection Considerations  . . . . . . . . . . . . . . . . 36
  101.    9.5 Flow Control Mapping between TCP and FC  . . . . . . . . . . . 36
  102.    10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
  103.    10.1 Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 37
  104.    10.2 FC Fabric and IP Network Deployment Models  . . . . . . . . . 39
  105.    10.3 FCIP Security Components  . . . . . . . . . . . . . . . . . . 39
  106.    10.3.1 IPsec ESP Authentication and Confidentiality  . . . . . . . 39
  107.    10.3.2 Key Management  . . . . . . . . . . . . . . . . . . . . . . 40
  108.  
  109.  
  110. Rajagopal, et al.               Standards Track                 [Page 2]
  111.  
  112. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  113.  
  114.  
  115.    10.3.3 ESP Replay Protection and Rekeying issues . . . . . . . . . 42
  116.    10.4 Secure FCIP Link Operation  . . . . . . . . . . . . . . . . . 43
  117.    10.4.1 FCIP Link Initialization Steps  . . . . . . . . . . . . . . 43
  118.    10.4.2 TCP Connection Security Associations (SAs)  . . . . . . . . 43
  119.    10.4.3 Handling data integrity and confidentiality violations  . . 43
  120.    11. Performance  . . . . . . . . . . . . . . . . . . . . . . . . . 44
  121.    11.1 Performance Considerations  . . . . . . . . . . . . . . . . . 44
  122.    11.2 IP Quality of Service (QoS) Support . . . . . . . . . . . . . 45
  123.    12. Normative References . . . . . . . . . . . . . . . . . . . . . 46
  124.    13. Informative References . . . . . . . . . . . . . . . . . . . . 47
  125.    14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 48
  126.    15. Contributors' Addresses  . . . . . . . . . . . . . . . . . . . 48
  127.    16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 51
  128.  
  129.    Appendix
  130.    A  Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 51
  131.    B  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 52
  132.    C  FCIP Usage of Addresses and Identifiers . . . . . . . . . . . . 52
  133.    D  Example of synchronization recovery algorithm . . . . . . . . . 53
  134.    E  Relationship between FCIP and IP over FC (IPFC) . . . . . . . . 58
  135.    F  FC Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 58
  136.    G  FC Encapsulation Format . . . . . . . . . . . . . . . . . . . . 60
  137.    H  FCIP Requirements on an FC Entity . . . . . . . . . . . . . . . 62
  138.  
  139.  
  140.  
  141.    Warning to Readers Familiar With Fibre Channel: Both Fibre
  142.    Channel and IETF standards use the same byte transmission order.
  143.    However, the bit and byte numbering is different. See appendix A
  144.    for guidance.
  145.  
  146.  
  147.  
  148. 1. Editors and Contributors
  149.  
  150.    During the development of this specification, Murali Rajagopal,
  151.    Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively
  152.    as editors. Raj Bhagwat contributed substantially to the initial
  153.    basic FCIP concepts.
  154.  
  155.    Venkat Rangan contributed the Security section and continues to
  156.    coordinate security issues with the ips Working Group and IETF.
  157.  
  158.    Andy Helland contributed a substantial revision of Performance
  159.    section, aligning it with TCP/IP QoS concepts.
  160.  
  161.    Dave Peterson contributed the dynamic discovery section and edits
  162.    the FCIP SLP internet-draft.
  163.  
  164.  
  165. Rajagopal, et al.               Standards Track                 [Page 3]
  166.  
  167. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  168.  
  169.  
  170.  
  171.    Anil Rijhsinghani contributed material related to the FCIP MIB and
  172.    edits the FCIP MIB internet-draft.
  173.  
  174.    Bob Snively contributed material related to error detection and
  175.    recovery including the bulk of the synchronization recovery example
  176.    annex.
  177.  
  178.    Lawrence J. Lamers contributed numerous ideas focused on keeping
  179.    FCIP compatible with B_Port devices.
  180.  
  181.    Milan Merhar contributed several of the FCIP conceptual
  182.    modifications necessary to support NATs.
  183.  
  184.    Don Fraser contributed material related to link failure detection
  185.    and reporting.
  186.  
  187.    Bill Krieg contributed a restructuring of the TCP Connection setup
  188.    sections that made them more linear with respect to time and more
  189.    readable.
  190.  
  191.    Several T11 leaders supported this effort and advised the editors of
  192.    this specification regarding coordination with T11 documents and
  193.    projects. These T11 leaders are: Jim Nelson (Framing and Signaling),
  194.    Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic
  195.    Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone),
  196.    Steve Wilson (Switch Fabric), and Michael O'Donnell (Security
  197.    Protocols).
  198.  
  199.  
  200. 2. Purpose, Motivation and Objectives
  201.  
  202.    Fibre Channel (FC) is a gigabit or multi-gigabit speed networking
  203.    technology primarily used to implement Storage Area Networks (SANs).
  204.    See section 3 for information about how Fibre Channel is
  205.    standardized and the relationship of this specification to Fibre
  206.    Channel standards.
  207.  
  208.    This specification describes mechanisms that allow the
  209.    interconnection of islands of Fibre Channel SANs over IP Networks to
  210.    form a unified SAN in a single Fibre Channel fabric. The motivation
  211.    behind defining these interconnection mechanisms is a desire to
  212.    connect physically remote FC sites allowing remote disk access, tape
  213.    backup, and live mirroring.
  214.  
  215.    Fibre Channel standards have chosen nominal distances between switch
  216.    elements that are less than the distances available in an IP
  217.    Network. Since Fibre Channel and IP Networking technologies are
  218.  
  219.  
  220. Rajagopal, et al.               Standards Track                 [Page 4]
  221.  
  222. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  223.  
  224.  
  225.    compatible, it is logical to turn to IP Networking for extending the
  226.    allowable distances between Fibre Channel switch elements.
  227.  
  228.    The fundamental assumption made in this specification is that the
  229.    Fibre Channel traffic is carried over the IP Network in such a
  230.    manner that the Fibre Channel Fabric and all Fibre Channel devices
  231.    on the Fabric are unaware of the presence of the IP Network. This
  232.    means that the FC datagrams must be delivered in such time as to
  233.    comply with existing Fibre Channel specifications. The FC traffic
  234.    may span LANs, MANs and WANs, so long as this fundamental assumption
  235.    is adhered to.
  236.  
  237.    The objectives of this document are to:
  238.  
  239.    1)  specify the encapsulation and mapping of Fibre Channel (FC)
  240.        frames employing FC Frame Encapsulation [20].
  241.  
  242.    2)  apply the mechanism described in 1) to an FC Fabric using an IP
  243.        network as an interconnect between two or more islands in an FC
  244.        Fabric.
  245.  
  246.    3)  address any FC concerns arising from tunneling FC traffic over
  247.        an IP-based network, including security, data integrity (loss),
  248.        congestion, and performance. This will be accomplished by
  249.        utilizing the existing IETF-specified suite of protocols.
  250.  
  251.    4)  be compatible with the referenced FC standards. While new work
  252.        may be undertaken in T11 to optimize and enhance FC Fabrics,
  253.        this specification REQUIRES conformance only to the referenced
  254.        FC standards.
  255.  
  256.    5)  be compatible with all applicable IETF standards so that the IP
  257.        Network used to extend an FC Fabric can be used concurrently for
  258.        other reasonable purposes.
  259.  
  260.    The objectives of this document do not include using an IP Network
  261.    as a replacement for the Fibre Channel Arbitrated Loop interconnect.
  262.    No definition is provided for encapsulating loop primitive signals
  263.    for transmission over an IP Network.
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275. Rajagopal, et al.               Standards Track                 [Page 5]
  276.  
  277. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  278.  
  279.  
  280.  
  281. 3. Relationship to Fibre Channel Standards
  282.  
  283. 3.1 Relevant Fibre Channel Standards
  284.  
  285.    FC is standardized as a family of American National Standards
  286.    developed by the T11 technical committee of INCITS (InterNational
  287.    Committee for Information Technology Standards). T11 has specified a
  288.    number of documents describing FC protocols, operations, and
  289.    services. T11 documents of interest to readers of this specification
  290.    include (but are not limited to):
  291.  
  292.     - FC-BB   - Fibre Channel Backbone [3]
  293.     - FC-BB-2 - Fibre Channel Backbone -2 [4]
  294.     - FC-SW-2 - Fibre Channel Switch Fabric -2 [5]
  295.     - FC-FS   - Fibre Channel Framing and Signaling [6]
  296.  
  297.    FC-BB and FC-BB-2 describe the relationship between an FC Fabric and
  298.    interconnect technologies not defined in by Fibre Channel standards
  299.    (e.g., ATM and SONET). FC-BB-2 is the Fibre Channel document
  300.    describing the relationships between FC and TCP/IP, including the FC
  301.    use of FCIP.
  302.  
  303.    FC-SW-2 describes the switch components of an FC Fabric and FC-FS
  304.    describes the FC Frame format and basic control features of Fibre
  305.    Channel.
  306.  
  307.    Additional information regarding T11 activities is available on the
  308.    committee's web site www.t11.org.
  309.  
  310. 3.2 This Specification and Fibre Channel Standards
  311.  
  312.    When considering the challenge of transporting FC Frames over an IP
  313.    Network, it is logical to divide the standardization effort between
  314.    TCP/IP requirements and Fibre Channel requirements. This
  315.    specification covers the TCP/IP requirements for transporting FC
  316.    Frames and the Fibre Channel documents described in section 3.1
  317.    cover the Fibre Channel requirements.
  318.  
  319.    This specification addresses only the requirements necessary to
  320.    properly utilize an IP Network as a conduit for FC Frames. The
  321.    result is a specification for an FCIP Entity (see section 6.4).
  322.  
  323.    A product that tunnels an FC Fabric through an IP Network MUST
  324.    combine the FCIP Entity with an FC Entity (see section 6.3) using an
  325.    implementation specific interface. The requirements placed on an FC
  326.    Entity by this specification to achieve proper delivery of FC Frames
  327.    are summarized in appendix H. More information about FC Entities can
  328.  
  329.  
  330. Rajagopal, et al.               Standards Track                 [Page 6]
  331.  
  332. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  333.  
  334.  
  335.    be found in the Fibre Channel standards and an example of an FC
  336.    Entity can be found in FC-BB-2 [4].
  337.  
  338.    No attempt is being made to define a specific API between an FCIP
  339.    Entity and an FC Entity. The approach is to specify required
  340.    functional interactions between an FCIP Entity and an FC Entity
  341.    (both of which are required to forward FC frames across an IP
  342.    Network), but allow implementers to choose how this will be realized.
  343.  
  344. 4. Terminology
  345.  
  346.    Terms used to describe FCIP concepts are defined in this section.
  347.  
  348.    FC End Node - A FC device that uses the connection services provided
  349.    by the FC Fabric.
  350.  
  351.    FC Entity - The Fibre Channel specific functional component that
  352.    combines with an FCIP Entity to form an interface between an FC
  353.    Fabric and an IP Network (see section 6.3).
  354.  
  355.    FC Fabric - An entity that interconnects various Nx_Ports (see [6])
  356.    attached to it, and is capable of routing FC Frames using only the
  357.    destination ID information in a FC Frame header (see appendix F).
  358.  
  359.    FC Fabric Entity - A Fibre Channel specific element containing one
  360.    or more Interconnect_Ports (see FC-SW-2 [5]) and one or more FC/FCIP
  361.    Entity pairs. See FC-BB-2 [4] for a details about FC Fabric Entities.
  362.  
  363.    FC Frame - The basic unit of Fibre Channel data transfer (see
  364.    appendix F).
  365.  
  366.    FC Frame Receiver Portal - The access point through which an FC
  367.    Frame and time stamp enters an FCIP Data Engine from the FC Entity.
  368.  
  369.    FC Frame Transmitter Portal - The access point through which a
  370.    reconstituted FC Frame and time stamp leaves an FCIP Data Engine to
  371.    the FC Entity.
  372.  
  373.    FC/FCIP Entity pair - The combination of one FC Entity and one FCIP
  374.    entity.
  375.  
  376.    FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that
  377.    handles FC Frame encapsulation, de-encapsulation, and transmission
  378.    FCIP Frames through a single TCP Connection (see section 6.6).
  379.  
  380.    FCIP Entity - The entity responsible for the FCIP protocol exchanges
  381.    on the IP Network and which encompasses FCIP_LEP(s) and FCIP Control
  382.    & Services module (see section 6.4).
  383.  
  384.  
  385. Rajagopal, et al.               Standards Track                 [Page 7]
  386.  
  387. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  388.  
  389.  
  390.  
  391.    FCIP Frame - An FC Frame plus the FC Frame Encapsulation [20]
  392.    header, encoded SOF and encoded EOF that contains the FC Frame (see
  393.    section 6.6.1).
  394.  
  395.    FCIP Link - One or more TCP Connections that connect one FCIP_LEP to
  396.    another (see section 6.2).
  397.  
  398.    FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that
  399.    that handles a single FCIP Link and contains one or more FCIP_DEs
  400.    (see section 6.5).
  401.  
  402.    Encapsulated Frame Receiver Portal - The TCP access point through
  403.    which an FCIP Frame is received from the IP Network by an FCIP Data
  404.    Engine.
  405.  
  406.    Encapsulated Frame Transmitter Portal - The TCP access point through
  407.    which an FCIP Frame is transmitted to the IP Network by an FCIP Data
  408.    Engine.
  409.  
  410.    FCIP Special Frame (FSF) - A specially formatted FC Frame containing
  411.    information used by the FCIP protocol (see section 8).
  412.  
  413. 5. Protocol Summary
  414.  
  415.    The FCIP protocol is summarized as follows:
  416.  
  417.    1)  The primary function of an FCIP Entity is forwarding FC Frames,
  418.        employing FC Frame Encapsulation described in [20].
  419.  
  420.    2)  Viewed from the IP Network perspective, FCIP Entities are peers
  421.        and communicate using TCP/IP. Each FCIP Entity contains one or
  422.        more TCP endpoints in the IP-based network.
  423.  
  424.    3)  Viewed from the FC Fabric perspective, pairs of FCIP Entities,
  425.        in combination with their associated FC Entities, forward FC
  426.        Frames between FC Fabric elements. The FC End Nodes are unaware
  427.        of the existence of the FCIP Link.
  428.  
  429.    4)  FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames
  430.        are not transmitted across an FCIP Link because they cannot be
  431.        encoded using FC Frame Encapsulation [20].
  432.  
  433.    5)  The path (route) taken by an encapsulated FC Frame follows the
  434.        normal routing procedures of the IP Network.
  435.  
  436.  
  437.  
  438.  
  439.  
  440. Rajagopal, et al.               Standards Track                 [Page 8]
  441.  
  442. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  443.  
  444.  
  445.    6)  An FCIP Entity MAY contain multiple FCIP Link Endpoints, but
  446.        each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one
  447.        other FCIP_LEP.
  448.  
  449.    7)  When multiple FCIP_LEPs with multiple FCIP_DEs are in use,
  450.        selection of which FCIP_DE to use for encapsulating and
  451.        transmitting a given FC Frame is covered in FC-BB-2 [4]. FCIP
  452.        Entities do not actively participate in FC Frame routing.
  453.  
  454.    8)  The FCIP Control & Services module MAY use TCP/IP quality of
  455.        service features (see section 11.2).
  456.  
  457.    9)  It is necessary to statically or dynamically configure each FCIP
  458.        entity with the IP addresses and TCP port numbers corresponding
  459.        to FCIP Entities with which it is expected to initiate
  460.        communication. If dynamic discovery of participating FCIP
  461.        Entities is supported, the function SHALL be performed using the
  462.        Service Location Protocol (SLPv2) [18]. It is outside the scope
  463.        of this specification to describe any static configuration
  464.        method for participating FCIP Entity discovery. Refer to section
  465.        9.1.2.2 for a detailed description of dynamic discovery of
  466.        participating FCIP Entities using SLPv2.
  467.  
  468.    10) Before creating a TCP Connection to a peer FCIP Entity, the FCIP
  469.        Entity attempting to create the TCP connection SHALL statically
  470.        or dynamically determine the IP address, TCP port, expected FC
  471.        Fabric Entity World Wide Name, TCP Connection Parameters, and
  472.        Quality of Service Information.
  473.  
  474.    11) FCIP Entities do not actively participate in the discovery of FC
  475.        source and destination identifiers. Discovery of FC addresses
  476.        (accessible via the FCIP Entity) is provided by techniques and
  477.        protocols within the FC architecture as described in FC-FS [6]
  478.        and FC-SW-2 [5].
  479.  
  480.    12) To support IP Network security (see section 10), FCIP Entities
  481.        MUST:
  482.        1)  implement cryptographically protected authentication and
  483.            cryptographic data integrity keyed to the authentication
  484.            process, and
  485.        2)  implement data confidentiality security features.
  486.  
  487.    13) On an individual TCP Connection, this specification relies on
  488.        TCP/IP to deliver a byte stream in the same order that it was
  489.        sent.
  490.  
  491.    14) This specification assumes the presence of and requires the use
  492.        of TCP and FC data loss and corruption mechanisms. The error
  493.  
  494.  
  495. Rajagopal, et al.               Standards Track                 [Page 9]
  496.  
  497. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  498.  
  499.  
  500.        detection and recovery features described in this specification
  501.        complement and support these existing mechanisms.
  502.  
  503. 6. The FCIP Model
  504.  
  505. 6.1 FCIP Protocol Model
  506.  
  507.    The relationship between FCIP and other protocols is illustrated in
  508.    figure 1.
  509.  
  510.        +------------------------+ FCIP Link +------------------------+
  511.        |          FCIP          |===========|          FCIP          |
  512.        +--------+------+--------+           +--------+------+--------+
  513.        |  FC-2  |      |  TCP   |           |  TCP   |      |  FC-2  |
  514.        +--------+      +--------+           +--------+      +--------+
  515.        |  FC-1  |      |   IP   |           |   IP   |      |  FC-1  |
  516.        +--------+      +--------+           +--------+      +--------+
  517.        |  FC-0  |      |  LINK  |           |  LINK  |      |  FC-0  |
  518.        +--------+      +--------+           +--------+      +--------+
  519.             |          |   PHY  |           |   PHY  |           |
  520.             |          +--------+           +--------+           |
  521.             |               |                    |               |
  522.             |               |     IP Network     |               |
  523.             V               +--------------------+               V
  524.          to Fibre                                             to Fibre
  525.          Channel                                              Channel
  526.          Fabric                                               Fabric
  527.  
  528. Key: FC-0 - Fibre Channel Physical Media Layer
  529.      FC-1 - Fibre Channel Encode and Decode Layer
  530.      FC-2 - Fibre Channel Framing and Flow Control Layer
  531.      TCP  - Transmission Control Protocol
  532.      IP   - Internet Protocol
  533.      LINK - IP Link Layer
  534.      PHY  - IP Physical Layer
  535.  
  536.        Fig. 1  FCIP Protocol Stack Model
  537.  
  538.    Note that the objective of the FCIP Protocol is creation and
  539.    maintenance of one or more FCIP Links to transport data.
  540.  
  541. 6.2 FCIP Link
  542.  
  543.    The FCIP Link is the basic unit of service provided by the FCIP
  544.    Protocol to an FC Fabric. As shown in figure 2, an FCIP Link
  545.    connects two portions of an FC Fabric using an IP Network as a
  546.    transport to form a single FC Fabric.
  547.  
  548.  
  549.  
  550. Rajagopal, et al.               Standards Track                [Page 10]
  551.  
  552. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  553.  
  554.  
  555.        /\/\/\/\/\/\         /\/\/\/\/\/\         /\/\/\/\/\/\
  556.        \    FC    /         \    IP    /         \    FC    /
  557.        /  Fabric  \=========/  Network \=========/  Fabric  \
  558.        \/\/\/\/\/\/         \/\/\/\/\/\/         \/\/\/\/\/\/
  559.                   |                              |
  560.                   |<--------- FCIP Link -------->|
  561.  
  562.        Fig. 2  FCIP Link Model
  563.  
  564.    At the points where the ends of the FCIP Link meet portions of the
  565.    FC Fabric, an FCIP Entity (see section 6.4) combines with an FC
  566.    Entity as described in section 6.3 to serve as the interface between
  567.    FC and IP.
  568.  
  569.    An FCIP Link SHALL contain at least one TCP Connection and MAY
  570.    contain more than one TCP Connection. The endpoints of a single TCP
  571.    Connection are FCIP Data Engines (see section 6.6). The endpoints of
  572.    a single FCIP Link are FCIP Link Endpoints (see section 6.5).
  573.  
  574. 6.3 FC Entity
  575.  
  576.    An implementation that tunnels an FC Fabric through an IP Network
  577.    MUST combine an FC Entity with an FCIP Entity (see section 6.4) to
  578.    form a complete interface between the FC Fabric and IP Network as
  579.    shown in figure 3. An FC Fabric Entity may contain multiple
  580.    instances of the FC/FCIP Entity pair shown on either the right-hand
  581.    or left-hand side of figure 3.
  582.  
  583.                   |<--------- FCIP Link -------->|
  584.                   |                              |
  585.        +----------+         /\/\/\/\/\/\         +----------+
  586.        |   FCIP   |         \    IP    /         |   FCIP   |
  587.        |  Entity  |=========/  Network \=========|  Entity  |
  588.        +----------+         \/\/\/\/\/\/         +----------+
  589.        |    FC    |                              |    FC    |
  590.        |  Entity  |                              |  Entity  |
  591.        +----------+                              +----------+
  592.             |                                         |
  593.        /\/\/\/\/\/\                              /\/\/\/\/\/\
  594.        \    FC    /                              \    FC    /
  595.        /  Fabric  \                              /  Fabric  \
  596.        \/\/\/\/\/\/                              \/\/\/\/\/\/
  597.  
  598.        Fig. 3  Model for Two Connected FC/FCIP Entity Pairs
  599.  
  600.    In general, the combination of an FCIP Link and two FC/FCIP Entity
  601.    pairs is intended to provide a non- Fibre Channel backbone transport
  602.    between Fibre Channel components. For example, this combination can
  603.  
  604.  
  605. Rajagopal, et al.               Standards Track                [Page 11]
  606.  
  607. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  608.  
  609.  
  610.    be used to function as the hard-wire connection between two Fibre
  611.    Channel switches.
  612.  
  613.    The interface between the FC and FCIP Entities is implementation
  614.    specific. The functional requirements placed on an FC Entity by this
  615.    specification are listed in appendix H. More information about FC
  616.    Entities can be found in the Fibre Channel standards and an example
  617.    of an FC Entity can be found in FC-BB-2 [4].
  618.  
  619. 6.4 FCIP Entity
  620.  
  621.    The model for an FCIP Entity is shown in figure 4.
  622.  
  623.        .......................................................
  624.        : FCIP Entity                                         :
  625.        :                                                     :
  626.        :  +-----------+                                      :
  627.        :  | FCIP      |                                      :
  628.        :  | Control & |------------------------------------+ :
  629.        :  | Services  |                                    | :
  630.        :  | Module    |                                    | :
  631.        :  +-----------+                                    | :
  632.        :        |            +--------------------+        | :
  633.        :        |   +-------+--------------------+|----+   | :
  634.        :        |   |+-----+--------------------+|----+|   | :
  635.        :        |   ||+----| FCIP Link Endpoint |----+||   | :
  636.        :        |   |||    +--------------------+    |||   | :
  637.        :.............................................|||.....:
  638.                 |   |||                              |||   |
  639.                 |   |||                              |||   o<--+
  640.                 |   |||                unique TCP    |||   |   |
  641.                 |   |||                connections-->|||   |   |
  642.                 |   |||                              |||   |   |
  643.              +----------+                         /\/\/\/\/\/\ |
  644.              |    FC    |                         \    IP    / |
  645.              |  Entity  |                         /  Network \ |
  646.              +----------+                         \/\/\/\/\/\/ |
  647.                   |                                            |
  648.              /\/\/\/\/\/\                   +------------------+
  649.              \    FC    /                   +->TCP port for
  650.              /  Fabric  \                      incoming
  651.              \/\/\/\/\/\/                      connections
  652.  
  653.        Fig. 4  FCIP Entity Model
  654.  
  655.    The FCIP Entity receives TCP connect requests on behalf of the
  656.    FCIP_LEPs that it manages. In support of this, the FCIP Entity is
  657.    the sole owner of at least one TCP port/IP Address combination used
  658.  
  659.  
  660. Rajagopal, et al.               Standards Track                [Page 12]
  661.  
  662. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  663.  
  664.  
  665.    to form TCP Connections. The TCP port may be the FCIP well known
  666.    port at a given IP Address. An FC Fabric to IP Network interface
  667.    product SHALL provide each FC/FCIP Entity pair contained in the
  668.    product with a unique combination of FC Fabric Entity World Wide
  669.    Identifier and FC/FCIP Entity Identifier values (see section 8).
  670.  
  671.    An FCIP Entity contains an FCIP Control & Services Module to control
  672.    FCIP link initialization, FCIP link dissolution, and to provide the
  673.    FC Entity with an interface to key IP Network features. The
  674.    interfaces to the IP Network features are implementation specific,
  675.    however, REQUIRED TCP/IP functional support is specified in this
  676.    document, including:
  677.  
  678.     - TCP Connections - see section 9
  679.     - Security - see section 10
  680.     - Performance - see section 11
  681.     - Dynamic Discovery - see section 9.1.2.2
  682.  
  683.    The FCIP Link Endpoints in an FCIP Entity provide the FC Frame
  684.    encapsulation and transmission features of FCIP.
  685.  
  686. 6.5 FCIP Link Endpoint (FCIP_LEP)
  687.  
  688.    As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data
  689.    Engine for each TCP Connection in the FCIP Link.
  690.  
  691.         ................................................
  692.         : FCIP Link Endpoint                           :
  693.         :                   +------------------+       :
  694.         :          +-------+------------------+|----+  :
  695.         :          |+-----+------------------+|----+|  :
  696.         :          ||+----| FCIP Data Engine |----+||  :
  697.         :          |||    +------------------+    |||  :
  698.         :..............................................:
  699.                    |||                            |||   
  700.               +----------+                    /\/\/\/\/\/\
  701.               |    FC    |                    \    IP    /
  702.               |  Entity  |                    /  Network \
  703.               +----------+                    \/\/\/\/\/\/
  704.                     |
  705.               /\/\/\/\/\/\
  706.               \    FC    /
  707.               /  Fabric  \
  708.               \/\/\/\/\/\/
  709.  
  710.        Fig. 5  FCIP Link Endpoint Model
  711.  
  712.  
  713.  
  714.  
  715. Rajagopal, et al.               Standards Track                [Page 13]
  716.  
  717. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  718.  
  719.  
  720.  
  721.  
  722.    Each time a TCP Connection is formed with a new FC/FCIP Entity pair
  723.    (including all the actions described in section 9.1), the FCIP
  724.    Entity SHALL create a new FCIP Link Endpoint containing one FCIP
  725.    Data Engine.
  726.  
  727.    An FCIP_LEP is a transparent data translation point between an FC
  728.    Entity and an IP Network. A pair of FCIP_LEPs communicating over one
  729.    or more TCP Connections create an FCIP Link to join two islands of a
  730.    FC Fabric, producing a single FC Fabric.
  731.  
  732.    The IP Network over which the two FCIP_LEPs communicate is not aware
  733.    of the FC payloads that it is carrying. Likewise, the FC End Nodes
  734.    connected to the FC Fabric are unaware of the TCP/IP based transport
  735.    employed in the structure of the FC Fabric.
  736.  
  737.    An FCIP_LEP uses normal TCP based flow control mechanisms for
  738.    managing its internal resources and matching them with the
  739.    advertised TCP Receiver Window Size (see section 9.5). An FCIP_LEP
  740.    MAY communicate with its local FC Entity counterpart to coordinate
  741.    flow control.
  742.  
  743.  
  744. 6.6 FCIP Data Engine (FCIP_DE)
  745.  
  746.    The model for one of the multiple FCIP_DEs that MAY be present in an
  747.    FCIP_LEP is shown in figure 6.
  748.  
  749.              +--------------------------------+
  750.              |                                |
  751.         F    |-+    +------------------+    +-|
  752.         C    |p|    |  Encapsulation   |    |p|    N
  753.           -->|1|--->|     Engine       |--->|2|--> e
  754.         E    |-+    +------------------+    +-|    t
  755.         n    |                                |  I w
  756.         t    |-+    +------------------+    +-|  P o
  757.         i    |p|    | De-Encapsulation |    |p|    r
  758.         t <--|4|<---|     Engine       |<---|3|<-- k
  759.         y    |-+    +------------------+    +-|
  760.              |                                |
  761.              +--------------------------------+
  762.  
  763.        Fig. 6  FCIP Data Engine Model
  764.  
  765.    Data enters and leaves the FCIP_DE through four portals (p1 - p4).
  766.    The portals do not process or examine the data that passes through
  767.    them. They are only the named access points where the FCIP_DE
  768.  
  769.  
  770. Rajagopal, et al.               Standards Track                [Page 14]
  771.  
  772. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  773.  
  774.  
  775.    interfaces with external world. The names of the portals are as
  776.    follows:
  777.  
  778.    p1) FC Frame Receiver Portal - The interface through which an FC
  779.        Frame and time stamp enters an FCIP_DE from the FC Entity.
  780.  
  781.    p2) Encapsulated Frame Transmitter Portal - The TCP interface
  782.        through which an FCIP Frame is transmitted to the IP Network by
  783.        an FCIP_DE.
  784.  
  785.    p3) Encapsulated Frame Receiver Portal - The TCP interface through
  786.        which an FCIP Frame is received from the IP Network by an FCIP_DE.
  787.  
  788.    p4) FC Frame Transmitter Portal - The interface through which a
  789.        reconstituted FC Frame and time stamp exits an FCIP_DE to the FC
  790.        Entity.
  791.  
  792.    The work of the FCIP_DE is done by the Encapsulation and De-
  793.    Encapsulation Engines. The Engines have two functions:
  794.  
  795.    1)  Encapsulating and de-encapsulating FC Frames using the
  796.        encapsulation format described in FC Frame Encapsulation [20]
  797.        and in section 6.6.1 of this document, and
  798.  
  799.    2)  Detecting some data transmission errors and performing minimal
  800.        error recovery as described in section 6.6.2.
  801.  
  802.    Data flows through a pair of IP Network connected FCIP_DEs in the
  803.    following seven steps:
  804.  
  805.    1)  An FC Frame and time stamp arrives at the FC Frame Receiver
  806.        Portal and is passed to the Encapsulation Engine. The FC Frame
  807.        is assumed to have been processed by the FC Entity according to
  808.        the applicable FC rules and is not validated by the FCIP_DE. If
  809.        the FC Entity is in the Unsynchronized state with respect to a
  810.        time base as described in the FC Frame Encapsulation [20]
  811.        specification, the time stamp delivered with the FC Frame SHALL
  812.        be zero.
  813.  
  814.    2)  In the Encapsulation Engine, the encapsulation format described
  815.        in FC Frame Encapsulation [20] and in section 6.6.1 of this
  816.        document SHALL be applied to prepare the FC Frame and associated
  817.        time stamp for transmission over the IP Network.
  818.  
  819.    3)  The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL
  820.        be passed to the Encapsulated Frame Transmitter Portal where it
  821.        SHALL be inserted in the TCP byte stream.
  822.  
  823.  
  824.  
  825. Rajagopal, et al.               Standards Track                [Page 15]
  826.  
  827. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  828.  
  829.  
  830.    4)  Transmission of the FCIP Frame over the IP Network follows all
  831.        the TCP rules of operation. This includes but is not limited to
  832.        the in-order delivery of bytes in the stream, as specified by
  833.        TCP [7].
  834.  
  835.    5)  The FCIP Frame arrives at the partner FCIP Entity where it
  836.        enters the FCIP_DE through the Encapsulated Frame Receiver
  837.        Portal and is passed to the De-Encapsulation Engine for
  838.        processing.
  839.  
  840.    6)  The De-Encapsulation Engine SHALL validate the incoming TCP byte
  841.        stream as described in section 6.6.2 and SHALL de-encapsulate
  842.        the FC Frame and associated time stamp according to the
  843.        encapsulation format described in FC Frame Encapsulation [20]
  844.        and in section 6.6.1 of this document.
  845.  
  846.    7)  In the absence of errors, the de-encapsulated FC Frame and time
  847.        stamp SHALL be passed to the FC Frame Transmitter Portal for
  848.        delivery to the FC Entity. Error handling is discussed in
  849.        section 6.6.2.2.
  850.  
  851.    Every FC Frame that arrives at the FC Frame Receiver Portal SHALL be
  852.    transmitted on the IP Network as described in steps 1 through 4
  853.    above. In the absence of errors, data bytes arriving at the
  854.    Encapsulated Frame Receiver Portal SHALL be de-encapsulated and
  855.    forwarded to the FC Frame Transmitter Portal as described in steps 5
  856.    through 7.
  857.  
  858. 6.6.1 FCIP Encapsulation of FC Frames
  859.  
  860.    The FCIP encapsulation of FC Frames employs FC Frame Encapsulation
  861.    [20].
  862.  
  863.    The features from FC Frame Encapsulation that are unique to
  864.    individual protocols SHALL be applied as follows for the FCIP
  865.    encapsulation of FC Frames.
  866.  
  867.    The Protocol# field SHALL contain 1 in accordance with the IANA
  868.    Considerations annex of FC Frame Encapsulation [20].
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880. Rajagopal, et al.               Standards Track                [Page 16]
  881.  
  882. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  883.  
  884.  
  885.    The Protocol Specific field SHALL have the format shown in figure 7.
  886.    Note: the word numbers in figure 7 are relative to the complete FC
  887.    Frame Encapsulation header, not to the Protocol Specific field.
  888.  
  889.     W|------------------------------Bit------------------------------|
  890.     o|                                                               |
  891.     r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
  892.     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|
  893.      +---------------------------------------------------------------+
  894.     1|               replication of encapsulation word 0             |
  895.      +---------------+---------------+---------------+---------------+
  896.     2|    pFlags     |    Reserved   |    -pFlags    |  -Reserved    |
  897.      +---------------+---------------+---------------+---------------+
  898.  
  899.        Fig. 7  FCIP Usage of FC Frame Encapsulation Protocol Specific
  900.            field
  901.  
  902.    Word 1 of the Protocol Specific field SHALL contain an exact copy of
  903.    word 0 in FC Frame Encapsulation [20].
  904.  
  905.    The pFlags (protocol specific flags) field provides information
  906.    about the protocol specific usage of the FC Encapsulation Header.
  907.    Figure 8 shows the defined pFlags bits.
  908.  
  909.        |----------------Bit--------------------|
  910.        |                                       |
  911.        |  0    1    2    3    4    5    6    7 |
  912.        +----+-----------------------------+----+
  913.        | Ch |          Reserved           | SF |
  914.        +----+-----------------------------+----+
  915.  
  916.        Fig. 8  pFlags Field Bits
  917.  
  918.    The SF (Special Frame) bit indicates whether the FCIP Frame is an
  919.    encapsulated FC Frame or an FSF (FCIP Special Frame, see section 8).
  920.    When the FCIP Frame contains an encapsulated FC Frame the SF bit
  921.    SHALL be 0. When the FCIP Frame is an FSF the SF bit SHALL be 1.
  922.  
  923.    The FSF SHALL only be sent as the first bytes transmitted in each
  924.    direction on a newly formed TCP Connection and only one FSF SHALL be
  925.    transmitted in each direction at that time (see section 9.1). After
  926.    that all FCIP Frames SHALL have the SF bit set to 0.
  927.  
  928.    The Ch (Changed) bit indicates whether an echoed FSF has been
  929.    intentionally altered (see section 9.1.3). The Ch bit SHALL be 0
  930.    unless the FSF bit is 1. When the initial TCP Connection FSF is
  931.    sent, the Ch bit SHALL be 0. If the recipient of a TCP connect
  932.    request echoes the FSF without any changes, then the Ch bit SHALL
  933.  
  934.  
  935. Rajagopal, et al.               Standards Track                [Page 17]
  936.  
  937. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  938.  
  939.  
  940.    continue to be 0. If the recipient of a TCP connect request alters
  941.    the FSF before echoing it, then the Ch bit SHALL be changed to 1.
  942.  
  943.    The -pFlags field SHALL contain the ones complement of the contents
  944.    of the pFlags field.
  945.  
  946.    Table 1 summarizes the usage of the pFlags SF and Ch bits.
  947.  
  948.        +----+----+------------+--------------------------------------+
  949.        |    |    | Originated |                                      |
  950.        | SF | Ch | or Echoed  | Validitity/Description               |
  951.        +----+----+------------+--------------------------------------+
  952.        |  0 |  0 |    n/a     | Encapsulated FC Frame                |
  953.        +----+----+------------+--------------------------------------+
  954.        |  0 |  1 |    n/a     | Always Illegal                       |
  955.        +----+----+------------+--------------------------------------+
  956.        |  1 |  0 | Originated | Originated FSF                       |
  957.        +----+----+------------+--------------------------------------+
  958.        |  1 |  1 | Originated | Always Illegal                       |
  959.        +----+----+------------+--------------------------------------+
  960.        |  1 |  0 |   Echoed   | Echoed FSF without changes           |
  961.        +----+----+------------+--------------------------------------+
  962.        |  1 |  1 |   Echoed   | Echoed FSF with changes              |
  963.        +----+----+------------+--------------------------------------+
  964.        | Note 1: Echoed FSFs may contain changes resulting from      |
  965.        | transmission errors, necessitating the comparison between   |
  966.        | sent and recieved FSF bytes by the FSF originator described |
  967.        | in section 9.1.2.3.                                         |
  968.        |                                                             |
  969.        | Note 2: Column positions in this table do not reflect the   |
  970.        | bit positions of the SF and Ch bits in the pFlags field.    |
  971.        +-------------------------------------------------------------+
  972.  
  973.        Table 1  pFlags SF and Ch bit usage summary
  974.  
  975.    The Reserved pFlags bits SHALL be 0.
  976.  
  977.    The Reserved field (bits 23-16 in word 2): SHALL contain 0.
  978.  
  979.    The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or 0xFF).
  980.  
  981.    The CRCV (CRC Valid) Flag SHALL be set to 0.
  982.  
  983.    The CRC field SHALL be set to 0.
  984.  
  985.    In FCIP, the SOF and EOF codes listed as Class 2, Class 3, and Class
  986.    4 in the FC Frame Encapsulation [20] are legal.
  987.  
  988.  
  989.  
  990. Rajagopal, et al.               Standards Track                [Page 18]
  991.  
  992. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  993.  
  994.  
  995.  
  996. 6.6.2 FCIP Data Engine Error Detection and Recovery
  997.  
  998. 6.6.2.1 TCP Assistance With Error Detection and Recovery
  999.  
  1000.    TCP [7] requires in order delivery, generation of TCP checksums, and
  1001.    checking of TCP checksums. Thus, the byte stream passed from TCP to
  1002.    the FCIP_LEP will be in order and free of errors detectable by the
  1003.    TCP checksum. The FCIP_LEP relies on TCP performing these functions.
  1004.  
  1005. 6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames
  1006.  
  1007.    Bytes delivered through the Encapsulated Frame Receiver Portal that
  1008.    are not correctly delimited as defined by the FC Frame Encapsulation
  1009.    [20] are considered to be in error.
  1010.  
  1011.    The failure of the Protocol# and Version fields in the FCIP Frame
  1012.    header to contain the values defined for an FCIP Frame SHALL be
  1013.    considered an error.
  1014.  
  1015.    Further, some errors in the encapsulation will result in the FCIP_DE
  1016.    losing synchronization with the FC Frames in the byte stream
  1017.    entering through the Encapsulated Frame Receiver Portal.
  1018.  
  1019.    The Frame Length field in the FC Frame Encapsulation header is used
  1020.    to determine where in the data stream the next FC Encapsulated
  1021.    Header is located. The following tests SHALL be performed to verify
  1022.    synchronization with the byte stream entering the Encapsulated Frame
  1023.    Receiver Portal, and synchronization SHALL be considered lost if any
  1024.    of the tests fail:
  1025.  
  1026.    1)  Frame Length field validation -- 15 < Frame Length < 545;
  1027.    2)  Comparison of Frame Length field to its ones complement; and
  1028.    3)  A valid EOF is found in the word preceding the start of the next
  1029.        FCIP header as indicated by the Frame Length field, to be tested
  1030.        as follows:
  1031.        1)  Bits 24-31 and 16-23 contain identical legal EOF values (the
  1032.            list of legal EOF values is in the FC Frame Encapsulation
  1033.            [20]); and
  1034.        2)  Bits 8-15 and 0-7 contain the ones complement of the EOF
  1035.            value found in bits 24-31.
  1036.  
  1037.    Note: The range of valid Frame Length values is derived as follows.
  1038.    The FCIP Frame header is seven words, one word each is require for
  1039.    the encoded SOF and EOF values, the FC Frame header is six words,
  1040.    and the FC CRC requires one word, yielding a base Frame Length of 16
  1041.    (7+1+1+6+1) words, if no FC Payload is present. Since the FC Payload
  1042.    is optional, any Frame Length value greater than 15 is valid. The
  1043.  
  1044.  
  1045. Rajagopal, et al.               Standards Track                [Page 19]
  1046.  
  1047. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1048.  
  1049.  
  1050.    maximum FC Payload size is 528 words, meaning that any Frame Length
  1051.    value up to and including 544 (528+16) is valid.
  1052.  
  1053.    If synchronization is lost, the FC Frame SHALL NOT be forwarded on
  1054.    to the FC Entity and further recovery SHALL be handled as defined by
  1055.    section 6.6.2.3.
  1056.  
  1057.    In addition to the tests above, the validity and positioning of the
  1058.    following FCIP Frame information SHOULD be used to detect
  1059.    encapsulation errors that may or may not affect synchronization:
  1060.  
  1061.    a)  Protocol# ones complement field (1 test);
  1062.    b)  Version ones complement field (1 test);
  1063.    c)  Replication of encapsulation word 0 in word 1 (1 test);
  1064.    d)  Reserved field and its ones complement (2 tests);
  1065.    e)  Flags field and its ones complement (2 tests);
  1066.    f)  CRC field is equal to zero (1 test);
  1067.    g)  SOF fields and ones complement fields (4 tests);
  1068.    h)  Format and values of FC header (1 test);
  1069.    i)  CRC of FC Frame (2 tests);
  1070.    j)  FC Frame Encapsulation header information in the next FCIP Frame
  1071.        (1 test).
  1072.  
  1073.    At least 3 of the 16 tests listed above SHALL be performed. Failure
  1074.    of any of the above tests actually performed SHALL indicate an
  1075.    encapsulation error and the FC Frame SHALL NOT be forwarded on to
  1076.    the FC Entity. Further, such errors SHOULD be considered carefully,
  1077.    since some may be synchronization errors.
  1078.  
  1079.    Whenever an FCIP_DE discards bytes delivered through the
  1080.    Encapsulated Frame Receiver Portal, it SHALL cause the FCIP Entity
  1081.    to notify the FC Entity of the condition and provide a suitable
  1082.    description of the reason bytes were discarded.
  1083.  
  1084.    The burden for recovering from discarded data falls on the FC Entity
  1085.    and other components of the FC Fabric and is outside the scope of
  1086.    this specification.
  1087.  
  1088. 6.6.2.3 Synchronization Failures
  1089.  
  1090.    If an FCIP_DE determines that it cannot find the next FCIP Frame
  1091.    header in the byte stream entering through the Encapsulated Frame
  1092.    Receiver Portal, the FCIP_DE SHALL one of the following:
  1093.  
  1094.    a)  close the TCP Connection [7] [8] and notify the FC Entity with
  1095.        the reason for the closure;
  1096.    b)  recover synchronization by searching the bytes delivered by the
  1097.        Encapsulated Frame Receiver Portal for a valid FCIP Frame header
  1098.  
  1099.  
  1100. Rajagopal, et al.               Standards Track                [Page 20]
  1101.  
  1102. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1103.  
  1104.  
  1105.        having the correct properties (see section 6.6.2.2), and
  1106.        discarding bytes delivered by the Encapsulated Frame Receiver
  1107.        Portal until a valid FCIP Frame header is found; or
  1108.    c)  attempt to recover synchronization as described in b) and if
  1109.        synchronization cannot be recovered close the TCP Connection as
  1110.        described in a) including notification of the FC Entity with the
  1111.        reason for the closure.
  1112.  
  1113.    If the FCIP_DE attempts to recover synchronization, the
  1114.    resynchronization algorithm used SHALL meet the following
  1115.    requirements:
  1116.  
  1117.    a)  discard or identify with an EOFa (see appendix section F.1)
  1118.        those FC Frames and fragments of FC Frames identified before
  1119.        synchronization has again been completely verified. The number
  1120.        of FC Frames not forwarded may vary based on the algorithm used;
  1121.  
  1122.    b)  return to forwarding FC Frames through the FC Frame Transmitter
  1123.        Portal only after synchronization on the transmitted FCIP Frame
  1124.        stream has been verified; and
  1125.  
  1126.    c)  close the TCP/IP connection if the algorithm ends without
  1127.        verifying successful synchronization. The probability of failing
  1128.        to synchronize successfully and the time necessary to determine
  1129.        whether or not synchronization was successful may vary with the
  1130.        algorithm used.
  1131.  
  1132.    An example algorithm meeting these requirements can be found in
  1133.    appendix D.
  1134.  
  1135.    The burden for recovering from the discarding of FCIP Frames during
  1136.    the optional resynchronization process described in this section
  1137.    falls on the FC Entity and other components of the FC Fabric and is
  1138.    outside the scope of this specification.
  1139.  
  1140. 7. Checking FC Frame Transit Times in the IP Network
  1141.  
  1142.    "FC-BB-2 [4] defines how the measurement of IP Network transit time
  1143.    is performed, based on the requirements stated in the FC Frame
  1144.    Encapsulation [20] specification. The choice to place this
  1145.    implementation requirement on the FC Entity is based on a desire to
  1146.    include the transit time through the FCIP Entities when computing
  1147.    the IP Network transit time experienced by the FC Frames.
  1148.  
  1149.    Each FC Frame that enters the FCIP_DE through the FC Frame Receiver
  1150.    Portal SHALL be accompanied by a time stamp value that the FCIP_DE
  1151.    SHALL place in the Time Stamp [integer] and Time Stamp [fraction]
  1152.    fields of the encapsulation header of the FCIP Frame that contains
  1153.  
  1154.  
  1155. Rajagopal, et al.               Standards Track                [Page 21]
  1156.  
  1157. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1158.  
  1159.  
  1160.    the FC Frame. If no synchronized time stamp value is available to
  1161.    accompany the entering FC Frame a value of zero SHALL be used.
  1162.  
  1163.    Each FC Frame that exits the FCIP_DE through the FC Frame
  1164.    Transmitter Portal SHALL be accompanied by the time stamp value
  1165.    taken from the FCIP Frame that encapsulated the FC Frame.
  1166.  
  1167.    The FC Entity SHALL use suitable internal clocks and either Fibre
  1168.    Channel services or an SNTP Version 4 server [26] to establish and
  1169.    maintain the required synchronized time value. The FC Entity SHALL
  1170.    verify that the FC Entity it is communicating with on an FCIP Link
  1171.    is using the same synchronized time source as it is, either Fibre
  1172.    Channel services or SNTP server.
  1173.  
  1174.    Note that since the FC Fabric is expected to have a single
  1175.    synchronized time value throughout, reliance on the Fibre Channel
  1176.    services means that only one synchronized time value is needed for
  1177.    all FCIP_DEs regardless of their connection characteristics.
  1178.  
  1179. 8. The FCIP Special Frame (FSF)
  1180.  
  1181. 8.1 FCIP Special Frame Format
  1182.  
  1183.    Figure 9 shows the FSF format.
  1184.  
  1185.     W|------------------------------Bit------------------------------|
  1186.     o|                                                               |
  1187.     r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
  1188.     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|
  1189.      +---------------+---------------+---------------+---------------+
  1190.     0|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
  1191.      |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
  1192.      +---------------+---------------+---------------+---------------+
  1193.     1|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
  1194.      |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
  1195.      +---------------+---------------+---------------+---------------+
  1196.     2|    pFlags     |    Reserved   |    -pFlags    |  -Reserved    |
  1197.      |               |     (0x00)    |               |    (0xFF)     |
  1198.      +-----------+---+---------------+-----------+---+---------------+
  1199.     3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
  1200.      | (0b000000)|  (0b0000010010)   | (0b111111)|   (0b1111101101)  |
  1201.      +-----------+-------------------+-----------+-------------------+
  1202.                                 (Continued)
  1203.  
  1204.        Fig. 9  FSF Format (part 1 of 2)
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210. Rajagopal, et al.               Standards Track                [Page 22]
  1211.  
  1212. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1213.  
  1214.  
  1215.     W|------------------------------Bit------------------------------|
  1216.     o|                                                               |
  1217.     r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
  1218.     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|
  1219.      |                                                               |
  1220.      |                          (Concluded)                          |
  1221.      +---------------------------------------------------------------+
  1222.     4|                      Time Stamp [integer]                     |
  1223.      +---------------------------------------------------------------+
  1224.     5|                      Time Stamp [fraction]                    |
  1225.      +---------------------------------------------------------------+
  1226.     6|                     CRC (Reserved in FCIP)                    |
  1227.      |                        (0x00-00-00-00)                        |
  1228.      +-------------------------------+-------------------------------+
  1229.     7|           Reserved            |          -Reserved            |
  1230.      |           (0x00-00)           |          (0xFF-FF)            |
  1231.      +-------------------------------+-------------------------------+
  1232.     8|                                                               |
  1233.      +-----        Source FC Fabric Entity World Wide Name      -----+
  1234.     9|                                                               |
  1235.      +---------------------------------------------------------------+
  1236.    10|                                                               |
  1237.      +-----           Source FC/FCIP Entity Identifier          -----+
  1238.    11|                                                               |
  1239.      +---------------------------------------------------------------+
  1240.    12|                                                               |
  1241.      +-----                   Connection Nonce                  -----+
  1242.    13|                                                               |
  1243.      +---------------+---------------+-------------------------------+
  1244.    14|   Connection  |    Reserved   |    Connection Usage Code      |
  1245.      |  Usage Flags  |     (0x00)    |     <defined in FC-BB-2>      |
  1246.      +---------------+---------------+-------------------------------+
  1247.    15|                                                               |
  1248.      +-----    Destination FC Fabric Entity World Wide Name     -----+
  1249.    16|                                                               |
  1250.      +---------------------------------------------------------------+
  1251.    17|                            K_A_TOV                            |
  1252.      +-------------------------------+-------------------------------+
  1253.    18|           Reserved            |          -Reserved            |
  1254.      |           (0x00-00)           |          (0xFF-FF)            |
  1255.      +-------------------------------+-------------------------------+
  1256.        Fig. 9 FSF Format (part 2 of 2)
  1257.  
  1258.    The FSF SHALL only be sent as the first bytes transmitted in each
  1259.    direction on a newly formed TCP Connection and only one FSF SHALL be
  1260.    transmitted in each direction.
  1261.  
  1262.  
  1263.  
  1264.  
  1265. Rajagopal, et al.               Standards Track                [Page 23]
  1266.  
  1267. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1268.  
  1269.  
  1270.    The contents of the FSF SHALL be as described for encapsulated FC
  1271.    Frames, except for the fields described in this section.
  1272.  
  1273.    All FSFs SHALL have the pFlags SF bit set to 1 (see section 6.6.1).
  1274.  
  1275.    The Source FC Fabric Entity World Wide Name field SHALL contain the
  1276.    Fibre Channel Name_Identifier [6] for the FC Fabric entity
  1277.    associated with the FC/FCIP Entity pair that generates (as opposed
  1278.    to echoes) the FSF. For example, if the FC Fabric entity is a FC
  1279.    Switch, the FC Fabric Entity World Wide Name field SHALL contain the
  1280.    Switch_Name [5]. The Source FC Fabric Entity World Wide Name SHALL
  1281.    be world wide unique.
  1282.  
  1283.    The Source FC/FCIP Entity Identifier field SHALL contain a unique
  1284.    identifier for the FC/FCIP Entity pair that generates (as opposed to
  1285.    echoes) the FSF. The value is assigned by the FC Fabric entity whose
  1286.    world wide name appears in the Source FC Fabric Entity World Wide
  1287.    Name field.
  1288.  
  1289.    Note: The combination of the Source FC Entity World Wide Name and
  1290.    Source FC/FCIP Entity Identifier fields uniquely identifies every FC/
  1291.    FCIP Entity pair in the IP Network.
  1292.  
  1293.    The Connection Nonce field shall contain a 64-bit random number
  1294.    generated to uniquely identify a single TCP connect request. In
  1295.    order to provide sufficient security for the connection nonce, the
  1296.    Randomness Recommendations for Security [10] SHOULD be followed.
  1297.  
  1298.    The Connection Usage Flags field identifies the types of SOF values
  1299.    [20] to be carried on the connection as shown in figure 10.
  1300.  
  1301.    |------------------------------Bit------------------------------|
  1302.    |                                                               |
  1303.    |    0      1       2       3       4       5       6       7   |
  1304.    +-------+-------+-------+-------+-------------------------------+
  1305.    |  SOFf | SOF?2 | SOF?3 | SOF?4 |            Reserved           |
  1306.    +-------+-------+-------+-------+-------------------------------+
  1307.  
  1308.        Fig. 10  Connection Usage Flags Field Format
  1309.  
  1310.    If the SOFf bit is one, then FC Frames containing SOFf are intended
  1311.    to be carried on the connection.
  1312.  
  1313.    If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2
  1314.    are intended to be carried on the connection.
  1315.  
  1316.    If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3
  1317.    are intended to be carried on the connection.
  1318.  
  1319.  
  1320. Rajagopal, et al.               Standards Track                [Page 24]
  1321.  
  1322. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1323.  
  1324.  
  1325.  
  1326.    If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and
  1327.    SOFc4 are intended to be carried on the connection.
  1328.  
  1329.    All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to
  1330.    one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then
  1331.    the types of FC Frames intended to be carried on the connection has
  1332.    no specific relationship to SOF code.
  1333.  
  1334.    The FCIP Entity SHALL NOT enforce the SOF usage described by the
  1335.    Connection Usage Flags field and SHALL only use the contents of the
  1336.    field as described below.
  1337.  
  1338.    The Connection Usage Code field contains Fibre Channel defined
  1339.    information regarding the intended usage of the connection as
  1340.    specified in FC-BB-2 [4].
  1341.  
  1342.    The FCIP Entity SHALL use the contents of the Connection Usage Flags
  1343.    and Connection Usage Code fields to locate appropriate QoS settings
  1344.    in the "shared" database of TCP Connection information (see section
  1345.    9.1.1) and apply those settings to a newly formed connection.
  1346.  
  1347.    The Destination FC Fabric Entity World Wide Name field MAY contain
  1348.    the Fibre Channel Name_Identifier [6] for the FC Fabric entity
  1349.    associated with the FC/FCIP Entity pair that echoes (as opposed to
  1350.    generates) the Special Frame.
  1351.  
  1352.    The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to
  1353.    be applied to the new TCP Connection as specified in FC-BB-2 [4].
  1354.  
  1355.    For each new incoming TCP connect request and subsequent FSF
  1356.    received, the FCIP Entity SHALL send the contents of the Source FC
  1357.    Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection
  1358.    Usage Flags and Connection Usage Code fields to the FC Entity along
  1359.    with the other connection information (e.g., FCIP_LEP and FCIP_DE
  1360.    information).
  1361.  
  1362. 8.2 Overview of FSF Usage in Connection Establishment
  1363.  
  1364.    When a new TCP Connection is established, an FCIP Special Frame
  1365.    makes one round trip from the FCIP Entity initiating the TCP connect
  1366.    operation to the FCIP Entity receiving the TCP connect request and
  1367.    back. This FSF usage serves three functions:
  1368.  
  1369.     - Identification of the FCIP Link endpoints
  1370.     - Conveyance of a few critical parameters shared by the FC/FCIP
  1371.       Entity pairs involved in the FCIP Link - Configuration discovery
  1372.       (used in place of SLP only when allowed by site security policies)
  1373.  
  1374.  
  1375. Rajagopal, et al.               Standards Track                [Page 25]
  1376.  
  1377. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1378.  
  1379.  
  1380.  
  1381.    The specific requirements for this usage of the FSF are found in
  1382.    section 9.1. This section provides an overview of the FSF usage
  1383.    without stating requirements.
  1384.  
  1385.    Because FCIP is only a tunnel for a Fibre Channel Fabric and because
  1386.    the Fabric has its own complex link setup algorithm that can be
  1387.    employed for many FCIP link setup needs, it is desirable to minimize
  1388.    the complexity of the FSF usage during TCP Connection setup. With
  1389.    this in mind, this FSF usage is not a login or parameter negotiation
  1390.    mechanism. A single FSF transits each newly established TCP
  1391.    connection as the first bytes sent in each direction.
  1392.  
  1393.    Note: This usage of the FSF cannot be eliminated entirely because a
  1394.    newly created TCP Connection must be associated with the correct
  1395.    FCIP Link before FC Fabric initialization of the connection can
  1396.    commence.
  1397.  
  1398.    The first bytes sent from the TCP connect request initiator to the
  1399.    receiver are an FSF identifying both the sender and who the sender
  1400.    thinks is the receiver. If the contents of this FSF are correct and
  1401.    acceptable to the receiver, the unchanged FSF is echoed back to the
  1402.    sender. This send/echo process is the only set of actions that
  1403.    allows the TCP Connection to be used to carry FC Fabric traffic. If
  1404.    the send and unchanged echo process does not occur, the algorithm
  1405.    followed at one or both ends of the TCP Connection results in the
  1406.    closure of the TCP Connection (see section 9.1 for specific
  1407.    algorithm requirements).
  1408.  
  1409.    Note: Owing to the limited manner in which the FSF is used and the
  1410.    requirement that the FSF be echoed without changes before a TCP
  1411.    Connection is allowed to carry user data, no error checking beyond
  1412.    that provided by TCP is deemed necessary.
  1413.  
  1414.    As described above, the primary purpose of the FSF usage during
  1415.    TCP Connection setup is identifying the FCIP Link to which the new
  1416.    TCP Connection belongs. From these beginnings, it is only a small
  1417.    stretch to envision using the FSF as a simplified configuration
  1418.    discovery tool, and the mechanics of such a usage are described
  1419.    in section 9.1.
  1420.  
  1421.    However, use of the FSF for configuration discovery lacks the broad
  1422.    range of capabilities provided by SLP v2 and most particularly lacks
  1423.    the security capabilities of SLP v2. For these reasons, using the
  1424.    FSF for configuration discovery is not appropriate for all
  1425.    environments. Thus the choice to use the FSF for discovery purposes
  1426.    is a policy choice to be included in the TCP Connection
  1427.    Establishment "shared" database described in section 9.1.1.
  1428.  
  1429.  
  1430. Rajagopal, et al.               Standards Track                [Page 26]
  1431.  
  1432. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1433.  
  1434.  
  1435.  
  1436.    When FSF-based configuration discovery is enabled, the normal TCP
  1437.    Connection setup rules outlined above are modified as follows.
  1438.  
  1439.    Normally, the algorithm executed by an FCIP Entity receiving an FSF
  1440.    includes verifying that its own identification information in the
  1441.    arriving FSF is correct and closing the TCP Connection if it is not.
  1442.    This can be viewed as requiring the initiator of a TCP connect
  1443.    request to know in advance the identity of the FCIP Entity that is
  1444.    the target of that request (using SLP, for example), and through the
  1445.    FSF effectively saying, "I think I'm talking to X." If the party at
  1446.    the other end of the TCP connect request is really Y, then it simply
  1447.    hangs up.
  1448.  
  1449.    FSF-based discovery allows the "I think I'm talking to X" to be
  1450.    replaced with "Please tell me who I am talking to?", which is
  1451.    accomplished by replacing an explicit value in the Destination FC
  1452.    Fabric Entity World Wide Name field with zero.
  1453.  
  1454.    If the policy at the receiving FCIP Entity allows FSF-based
  1455.    discovery, the zero is replaced with the correct Destination FC
  1456.    Fabric Entity World Wide Name value in the echoed FSF. This is still
  1457.    subject to the rules of sending with unchanged echo, and so closure
  1458.    of TCP Connection occurs after the echoed FSF is received by the TCP
  1459.    connect initiator.
  1460.  
  1461.    Despite the TCP Connection closure, however, the TCP connect
  1462.    initiator now knows the correct Destination FC Fabric Entity World
  1463.    Wide Name identity of the FCIP Entity at a given IP Address and a
  1464.    subsequent TCP Connection setup sequence probably will be successful.
  1465.  
  1466.    The Ch bit in the pFlags field (see section 6.6.1) allows for
  1467.    differentiation between changes in the FSF resulting from
  1468.    transmission errors and changes resulting from intentional acts by
  1469.    the FSF recipient.
  1470.  
  1471. 9. TCP Connection Management
  1472.  
  1473. 9.1 TCP Connection Establishment
  1474.  
  1475. 9.1.1 Connection Establishment Model
  1476.  
  1477.    The description of the connection establishment process in section
  1478.    9.1 is a model for the interactions between an FC Entity and an FCIP
  1479.    Entity during TCP Connection establishment. The model is written in
  1480.    terms of a "shared" database that the FCIP Entity consults to
  1481.    determine the properties of the TCP Connections to be formed
  1482.    combined with routine calls to the FC Entity when connections are
  1483.  
  1484.  
  1485. Rajagopal, et al.               Standards Track                [Page 27]
  1486.  
  1487. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1488.  
  1489.  
  1490.    successfully established. Whether the FC Entity contributes
  1491.    information to the "shared" database is not critical to this model.
  1492.    What is important is the fact that the FCIP Entity MAY consult the
  1493.    database at any time to determine its actions relative to TCP
  1494.    Connection establishment.
  1495.  
  1496.    It is important to remember that this description is only a model
  1497.    for the interactions between an FC Entity and an FCIP Entity. Any
  1498.    implementation that has the same effects on the FC Fabric and IP
  1499.    Network as those described in the model meets the requirements of
  1500.    this specification. For example, an implementation might replace the
  1501.    "shared" database with a routine interface between the FC and FCIP
  1502.    Entities.
  1503.  
  1504. 9.1.2 Creating New TCP Connections
  1505.  
  1506. 9.1.2.1 Non-Dynamic Creation of New TCP Connections
  1507.  
  1508.    When an FCIP Entity discovers that a new TCP Connection needs to be
  1509.    established, it SHALL determine the IP Address to which the TCP
  1510.    Connection is to be made and establish all enabled IP security
  1511.    features for that IP Address as described in section 10. Then the
  1512.    FCIP Entity SHALL determine the following information about the new
  1513.    connection in addition to the IP Address:
  1514.  
  1515.     - The expected Destination FC Fabric Entity World Wide Name of the
  1516.       FC/FCIP Entity pair to which the TCP Connection is being made
  1517.     - TCP Connection Parameters (see section 9.3)
  1518.     - Quality of Service Information (see section 11)
  1519.  
  1520.    Based on this information, the FCIP Entity SHALL generate a TCP
  1521.    connect request [7] to the FCIP Well-Known Port of 3225 (or other
  1522.    configuration specific port number) at the specified IP Address.
  1523.  
  1524.    If the TCP connect request is rejected, the FCIP Entity SHALL act to
  1525.    limit unnecessary repetition of attempts to establish similar
  1526.    connections. For example, the FCIP Entity might wait 60 seconds
  1527.    before trying to re-establish the connection.
  1528.  
  1529.    If the TCP connect request is accepted, the FCIP Entity SHALL follow
  1530.    the steps described in section 9.1.2.3 to complete the establishment
  1531.    of a new FCIP_DE.
  1532.  
  1533.    It is RECOMMENDED that an FCIP Entity not initiate TCP connect
  1534.    requests to another FCIP Entity if incoming TCP connect requests
  1535.    from that FCIP Entity have already been accepted.
  1536.  
  1537.  
  1538.  
  1539.  
  1540. Rajagopal, et al.               Standards Track                [Page 28]
  1541.  
  1542. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1543.  
  1544.  
  1545. 9.1.2.2 Dynamic Creation of New TCP Connections
  1546.  
  1547.    If dynamic discovery of participating FCIP Entities is supported the
  1548.    function SHALL be performed using the Service Location Protocol
  1549.    (SLPv2) [18] in the manner defined for FCIP usage [21].
  1550.  
  1551.    Upon discovering that dynamic discovery is to be used, the FCIP
  1552.    Entity SHALL enable IP security features for the SLP discovery
  1553.    process as described in [21] and then:
  1554.  
  1555.    1)  Determine the one or more FCIP Discovery Domain(s) to be used in
  1556.        the dynamic discovery process;
  1557.  
  1558.    2)  Establish an SLPv2 Service Agent to advertise the availability
  1559.        of this FCIP Entity to peer FCIP Entities in the identified FCIP
  1560.        Discovery Domain(s); and
  1561.  
  1562.    3)  Establish an SLPv2 User Agent to locate service advertisements
  1563.        for peer FCIP Entities in the identified FCIP Discovery Domain(s).
  1564.  
  1565.    For each peer FCIP Entity dynamically discovered through the SLPv2
  1566.    User Agent, the FCIP Entity SHALL establish all enabled IP security
  1567.    features for the discovered IP Address as described in section 10
  1568.    and then determine the following information about the new connection:
  1569.  
  1570.     - The expected Destination FC Fabric Entity World Wide Name of the
  1571.       FC/FCIP Entity pair to which the TCP Connection is being made
  1572.     - TCP Connection Parameters (see section 9.3)
  1573.     - Quality of Service Information (see section 11)
  1574.  
  1575.    Based on this information, the FCIP Entity SHALL generate a TCP
  1576.    connect request [7] to the FCIP Well-Known Port of 3225 (or other
  1577.    configuration specific port number) at the IP Address specified by
  1578.    the service advertisement. If the TCP connect request is rejected,
  1579.    act to limit unnecessary repetition of attempts to establish similar
  1580.    connections. If the TCP connect request is accepted, the FCIP Entity
  1581.    SHALL follow the steps described in section 9.1.2.3 to complete the
  1582.    establishment of a new FCIP_DE.
  1583.  
  1584.    It is recommended that an FCIP Entity not initiate TCP connect
  1585.    requests to another FCIP Entity if incoming TCP connect requests
  1586.    from that FCIP Entity have already been accepted.
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595. Rajagopal, et al.               Standards Track                [Page 29]
  1596.  
  1597. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1598.  
  1599.  
  1600. 9.1.2.3 Connection Setup After a Successful TCP Connect Request
  1601.  
  1602.    Whether Non-Dynamic TCP Connection creation (see section 9.1.2.1) or
  1603.    Dynamic TCP Connection creation (see section 9.1.2.2) is used, the
  1604.    steps described in this section SHALL be followed to take the TCP
  1605.    Connection setup process to completion.
  1606.  
  1607.    After the TCP connect request has been accepted, the FCIP Entity
  1608.    SHALL send an FCIP Special Frame (FSF, see section 8) as the first
  1609.    bytes transmitted on the newly formed connection and retain a copy
  1610.    of those bytes for later comparisons. All fields in the FSF SHALL be
  1611.    filled in as described in section 8, particularly:
  1612.  
  1613.     - The Source FC Fabric Entity World Wide Name field SHALL contain
  1614.       the FC Fabric Entity World Wide Name for the FC/FCIP Entity pair
  1615.       that is originating the TCP connect request;
  1616.     - The Source FC/FCIP Entity Identifier field SHALL contain a
  1617.       unique identifier that is assigned by the FC Fabric entity whose
  1618.       world wide name appears in the Source FC Fabric Entity World
  1619.       Wide Name field;
  1620.     - The Connection Nonce field SHALL contain a 64-bit random number
  1621.       that differs in value from any recently used Connection Nonce
  1622.       value. In order to provide sufficient security for the
  1623.       connection nonce, the Randomness Recommendations for Security
  1624.       [10] SHOULD be followed; and
  1625.     - The Destination FC Fabric Entity World Wide Name field SHALL
  1626.       contain 0 or the expected FC Fabric Entity World Wide Name for
  1627.       the FC/FCIP Entity pair that is destination the TCP connect
  1628.       request.
  1629.  
  1630.    After the FSF is sent on the newly formed connection, the FCIP
  1631.    Entity SHALL wait for the FSF to be echoed as the first bytes
  1632.    received on the newly formed connection.
  1633.  
  1634.    The FCIP Entity MAY apply a timeout of not less than 90 seconds to
  1635.    the waiting for the echoed FSF bytes and if the timeout expires the
  1636.    FCIP Entity SHALL close the TCP Connection and notify the FC Entity
  1637.    with the reason for the closure.
  1638.  
  1639.    If the echoed FSF bytes do not exactly match the FSF bytes sent
  1640.    (words 7 through 17 inclusive) or if the echoed Destination FC
  1641.    Fabric Entity World Wide Name field contains zero, the FCIP Entity
  1642.    SHALL close the TCP Connection and notify the FC Entity with the
  1643.    reason for the closure.
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650. Rajagopal, et al.               Standards Track                [Page 30]
  1651.  
  1652. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1653.  
  1654.  
  1655.  
  1656.    The FCIP Entity SHALL performed the following steps only if the
  1657.    echoed FSF bytes exactly match the FSF bytes sent (words 7 through
  1658.    17 inclusive).
  1659.  
  1660.    1)  Instantiate the appropriate Quality of Service (see section 11)
  1661.        conditions on the newly created TCP Connection,
  1662.  
  1663.    2)  If the IP Address and TCP Port to which the TCP Connection was
  1664.        made is not associated with any other FCIP_LEP, create a new
  1665.        FCIP_LEP for the new FCIP Link,
  1666.  
  1667.    3)  Create a new FCIP_DE within the newly created FCIP_LEP to
  1668.        service the new TCP Connection, and
  1669.  
  1670.    4)  Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination
  1671.        FC Fabric Entity World Wide Name, Connection Usage Flags and
  1672.        Connection Usage Code.
  1673.  
  1674. 9.1.3 Processing Incoming TCP Connect Requests
  1675.  
  1676.    The FCIP Entity SHALL listen for new TCP Connection requests [7] on
  1677.    the FCIP Well-Known Port (3225). An FCIP Entity MAY also accept and
  1678.    establish TCP Connections to a TCP port number other than the FCIP
  1679.    Well-Known Port, as configured by the network administrator in a
  1680.    manner outside the scope of this specification.
  1681.  
  1682.    The FCIP Entity SHALL determine the following information about the
  1683.    requested connection:
  1684.  
  1685.     - Whether the "shared" database (see section 9.1.1) allows the
  1686.       requested connection
  1687.     - Whether IP security setup has been performed for the IP security
  1688.       features enabled on the connection (see section 10)
  1689.  
  1690.    If the requested connection is not allowed, the FCIP Entity SHALL
  1691.    reject the connect request using appropriate TCP means. If the
  1692.    requested connection is allowed, the FC Entity SHALL ensure that
  1693.    required IP security features are enabled and accept the TCP connect
  1694.    request.
  1695.  
  1696.    After the TCP connect request has been accepted, the FCIP Entity
  1697.    SHALL wait for the FSF sent by the originator of the TCP connect
  1698.    request (see section 9.1.2) as the first bytes received on the
  1699.    accepted connection.
  1700.  
  1701.    The FCIP Entity MAY apply a timeout of not less than 90 seconds to
  1702.    the waiting for the FSF bytes and if the timeout expires the FCIP
  1703.  
  1704.  
  1705. Rajagopal, et al.               Standards Track                [Page 31]
  1706.  
  1707. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1708.  
  1709.  
  1710.    Entity SHALL close the TCP Connection and notify the FC Entity with
  1711.    the reason for the closure.
  1712.  
  1713.    Note: One method for attacking the security of the FCIP Link
  1714.    formation process (detailed in section 10.1) depends on keeping a
  1715.    TCP connect request open without sending an FSF. Implementations
  1716.    should bear this in mind in the handling of TCP connect requests
  1717.    where the FSF is not sent in a timely manner.
  1718.  
  1719.    Upon receipt of the FSF sent by the originator of the TCP connect
  1720.    request, the FCIP Entity SHALL inspect the contents of the following
  1721.    fields:
  1722.  
  1723.     - Connection Nonce,
  1724.     - Destination FC Fabric Entity World Wide Name,
  1725.     - Connection Usage Flags, and
  1726.     - Connection Usage Code.
  1727.  
  1728.    If the Connection Nonce field contains a value identical to the most
  1729.    recently received Connection Nonce from the same IP Address, the
  1730.    FCIP Entity SHALL close the TCP Connection and notify the FC Entity
  1731.    with the reason for the closure.
  1732.  
  1733.    If an FCIP Entity receives a duplicate FSF during the FCIP Link
  1734.    formation process, it SHALL close that TCP Connection and notify the
  1735.    FC Entity with the reason for the closure.
  1736.  
  1737.    If the Destination FC Fabric Entity World Wide Name contains 0, the
  1738.    FCIP Entity SHALL take one of the following three actions:
  1739.  
  1740.    1)  Leave the Destination FC Fabric Entity World Wide Name field and
  1741.        Ch bit both 0;
  1742.    2)  Change the Destination FC Fabric Entity World Wide Name field to
  1743.        match FC Fabric Entity World Wide Name associated with the FCIP
  1744.        Entity that received the TCP connect request and change the Ch
  1745.        bit to 1; or
  1746.    3)  Close the TCP Connection without sending any response.
  1747.  
  1748.    The choice between the above actions depends on the anticipated
  1749.    usage of the FCIP Entity. The FCIP Entity may consult the "shared"
  1750.    database when choosing between the above actions.
  1751.  
  1752.    If:
  1753.    a)  The Destination FC Fabric Entity World Wide Name contains a non-
  1754.        zero value that does not match the FC Fabric Entity World Wide
  1755.        Name associated with the FCIP Entity that received the TCP
  1756.        connect request, or
  1757.  
  1758.  
  1759.  
  1760. Rajagopal, et al.               Standards Track                [Page 32]
  1761.  
  1762. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1763.  
  1764.  
  1765.    b)  The contents of the Connection Usage Flags, and Connection Usage
  1766.        Code fields is not acceptable to the FCIP Entity that received
  1767.        the TCP connect request,
  1768.    then the FCIP Entity SHALL take one of the following two actions:
  1769.    1)  Change the contents of the unacceptable fields to correct/
  1770.        acceptable values and set the Ch bit to 1; or
  1771.    2)  Close the TCP Connection without sending any response.
  1772.  
  1773.    If the FCIP Entity makes any changes in the content of the FSF, it
  1774.    SHALL also set the Ch bit to 1.
  1775.  
  1776.    If any changes have been made in the received FSF during the
  1777.    processing described above, the following steps SHALL be performed:
  1778.  
  1779.    1)  The changed FSF SHALL be echoed to the originator of the TCP
  1780.        connect request as the only bytes transmitted on the accepted
  1781.        connection;
  1782.    2)  The TCP Connection SHALL be closed (the FC Entity need not be
  1783.        notified of the TCP Connection closure in this case because it
  1784.        is not indicative of an error); and
  1785.    3)  All of the additional processing described in this section SHALL
  1786.        be skipped.
  1787.  
  1788.    The remaining steps in this section SHALL be performed only if the
  1789.    FCIP Entity has not changed the contents of the above mentioned
  1790.    fields to correct/acceptable values.
  1791.  
  1792.    If the Source FC Fabric Entity World Wide Name and Source FC/FCIP
  1793.    Entity Identifier field values in the FSF do not match the Source FC
  1794.    Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier
  1795.    associated with any other FCIP_LEP, the FCIP Entity SHALL:
  1796.  
  1797.    1)  Echo the unchanged FSF to the originator of the TCP connect
  1798.        request as the first bytes transmitted on the accepted connection;
  1799.  
  1800.    2)  Instantiate the appropriate Quality of Service (see section 11)
  1801.        conditions on the newly created TCP Connection, considering the
  1802.        Connection Usage Flags and Connection Usage Code fields and
  1803.        "shared" database information (see section 9.1.1) as appropriate,
  1804.  
  1805.    3)  Create a new FCIP_LEP for the new FCIP Link,
  1806.  
  1807.    4)  Create a new FCIP_DE within the newly created FCIP_LEP to
  1808.        service the new TCP Connection, and
  1809.  
  1810.    5)  Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC
  1811.        Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier,
  1812.        Connection Usage Flags and Connection Usage Code.
  1813.  
  1814.  
  1815. Rajagopal, et al.               Standards Track                [Page 33]
  1816.  
  1817. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1818.  
  1819.  
  1820.  
  1821.    If the Source FC Fabric Entity World Wide Name and Source FC/FCIP
  1822.    Entity Identifier field values in the FCIP Special Frame match the
  1823.    Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity
  1824.    Identifier associated with an existing FCIP_LEP, the FCIP Entity
  1825.    SHALL:
  1826.  
  1827.    1)  Request that the FC Entity authenticate the source of TCP
  1828.        connect request (see FC-BB-2 [4]), providing the following
  1829.        information to the FC Entity for authentication purposes:
  1830.        a)  Source FC Fabric Entity World Wide Name,
  1831.        b)  Source FC/FCIP Entity Identifier, and
  1832.        c)  Connection Nonce.
  1833.        The FCIP Entity SHALL NOT use the new TCP Connection for any
  1834.        purpose until the FC Entity authenticates the source of the TCP
  1835.        connect request. If the FC Entity indicates that the TCP connect
  1836.        request cannot be properly authenticated, the FCIP Entity SHALL
  1837.        close the TCP Connection and skip all of the remaining steps in
  1838.        this section.
  1839.  
  1840.        The definition of the FC Entity SHALL include an authentication
  1841.        mechanism for use in response to a TCP connect request source
  1842.        that communicates with the partner FC/FCIP Entity pair on an
  1843.        existing FCIP Link. This authentication mechanism should use a
  1844.        previously authenticated TCP Connection in the existing FCIP
  1845.        Link to authenticate the Connection Nonce sent in then new TCP
  1846.        Connection setup process. The FCIP Entity SHALL treat failure of
  1847.        this authentication an authentication failure for the new TCP
  1848.        Connection setup process.
  1849.  
  1850.    2)  Echo the unchanged FSF to the originator of the TCP connect
  1851.        request as the first bytes transmitted on the accepted connection;
  1852.  
  1853.    3)  Instantiate the appropriate Quality of Service (see section 11)
  1854.        conditions on the newly created TCP Connection, considering the
  1855.        Connection Usage Flags and Connection Usage Code fields and
  1856.        "shared" database information (see section 9.1.1) as appropriate,
  1857.  
  1858.    4)  Create a new FCIP_DE within the existing FCIP_LEP to service the
  1859.        new TCP Connection, and
  1860.  
  1861.    5)  Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity
  1862.        World Wide Name, Source FC/FCIP Entity Identifier, Connection
  1863.        Usage Flags, Connection Usage Code and new FCIP_DE.
  1864.  
  1865.    Note that the originator of TCP connect requests uses IP Address and
  1866.    TCP Port to identify which TCP Connections belong to which FCIP_LEPs
  1867.    while the recipient of TCP connect requests uses the Source FC
  1868.  
  1869.  
  1870. Rajagopal, et al.               Standards Track                [Page 34]
  1871.  
  1872. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1873.  
  1874.  
  1875.    Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier
  1876.    fields from the FSF to identify which TCP Connection belong to which
  1877.    FCIP_LEPs. For this reason, an FCIP Entity that both originates and
  1878.    receives TCP connect requests is unable to match the FCIP_LEPs
  1879.    associated with originated TCP connect requests to the FCIP_LEPs
  1880.    associated with received TCP connect requests.
  1881.  
  1882. 9.1.4 Simultaneous Connection Establishment
  1883.  
  1884.    If two FCIP Entities perform simultaneous open operations, then two
  1885.    TCP Connections are formed and the SF originates at one end on one
  1886.    connection and at the other end on the other. Connection setup
  1887.    proceeds as described above on both connections, and the steps
  1888.    described above properly result in the formation of two FCIP Links
  1889.    between the same FCIP Entities.
  1890.  
  1891.    This is not an error. Fibre Channel is perfectly capable of handling
  1892.    to approximately equal connections between FC Fabric elements.
  1893.  
  1894.    The decision to setup pairs of FCIP Links in this manner is
  1895.    considered to be a site policy decision that can be covered in the
  1896.    "shared" database described in section 9.1.1.
  1897.  
  1898. 9.2 Closing TCP Connections
  1899.  
  1900.    The FCIP Entity SHALL provide a mechanism with acknowledgement by
  1901.    which the FC Entity is able to cause the closing of an existing TCP
  1902.    Connection at any time. This allows the FC Entity to close TCP
  1903.    Connections that are producing too many errors, etc.
  1904.  
  1905. 9.3 TCP Connection Parameters
  1906.  
  1907.    In order to provide efficient management of FCIP_LEP resources as
  1908.    well as FCIP Link resources, consideration of certain TCP Connection
  1909.    parameters is recommended.
  1910.  
  1911. 9.3.1 TCP Selective Acknowledgement Option
  1912.  
  1913.    The Selective Acknowledgement option RFC 2883 [19] allows the
  1914.    receiver to acknowledge multiple lost packets in a single ACK,
  1915.    enabling faster recovery. An FCIP Entity MAY negotiate use of TCP
  1916.    SACK and use it for faster recovery from lost packets and holes in
  1917.    TCP sequence number space.
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925. Rajagopal, et al.               Standards Track                [Page 35]
  1926.  
  1927. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1928.  
  1929.  
  1930. 9.3.2 TCP Window Scale Option
  1931.  
  1932.    The TCP Window Scale option [9] allows TCP window sizes larger than
  1933.    16-bit limits to be advertised by the receiver. It is necessary to
  1934.    allow data in long fat networks to fill the available pipe. This
  1935.    also implies buffering on the TCP sender that matches the
  1936.    (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses
  1937.    locally available mechanisms to set a window size that matches the
  1938.    available local buffer resources and the desired throughput.
  1939.  
  1940. 9.3.3 Protection against sequence number wrap
  1941.  
  1942.    It is RECOMMENDED that FCIP Entities implement protection against
  1943.    wrapped sequence numbers PAWS [9]. It is quite possible that within
  1944.    a single connection, TCP sequence numbers wrap within a timeout
  1945.    window.
  1946.  
  1947. 9.3.4 TCP_NODELAY Option
  1948.  
  1949.    FCIP Entities should disable the Nagle Algorithm as described in RFC
  1950.    1122 [8] Section 4.2.3.4. By tradition, this can be accomplished by
  1951.    setting the TCP_NODELAY option to one at the local TCP interface.
  1952.  
  1953. 9.4 TCP Connection Considerations
  1954.  
  1955.    In idle mode, a TCP Connection "keep alive" option of TCP is
  1956.    normally used to keep a connection alive. However, this timeout is
  1957.    fairly large and may prevent early detection of loss of
  1958.    connectivity. In order to facilitate faster detection of loss of
  1959.    connectivity, FC Entities SHOULD implement some form of Fibre
  1960.    Channel connection failure detection (see FC-BB-2 [4]).
  1961.  
  1962.    When an FCIP Entity discovers that TCP connectivity has been lost,
  1963.    the FCIP Entity SHALL notify the FC Entity of the failure including
  1964.    information about the reason for the failure.
  1965.  
  1966. 9.5 Flow Control Mapping between TCP and FC
  1967.  
  1968.    The FCIP Entity and FC Entity are connected to the IP Network and FC
  1969.    Fabric, respectively, and they need to follow the flow control
  1970.    mechanisms of both TCP and FC, which work independent of each other.
  1971.  
  1972.    This section provides guidelines as to how the FCIP Entity can map
  1973.    TCP flow control to status notifications to the FC Entity.
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980. Rajagopal, et al.               Standards Track                [Page 36]
  1981.  
  1982. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  1983.  
  1984.  
  1985.    There are two scenarios when the flow control management becomes
  1986.    crucial:
  1987.  
  1988.    1)  When there is line speed mismatch between the FC and IP
  1989.        interfaces.
  1990.  
  1991.        Even though it is RECOMMENDED that both the FC and IP interfaces
  1992.        to the FC Entity and FCIP Entity, respectively, be of comparable
  1993.        speeds, it is possible to carry FC traffic over an IP Network
  1994.        that has a different line speed and bit error rate.
  1995.  
  1996.    2)  When the FC Fabric or IP Network encounters congestion.
  1997.  
  1998.        Even when both the FC Fabric or IP network are of comparable
  1999.        speeds, during the course of operation the FC Fabric or the IP
  2000.        Network could encounter congestion due to transient conditions.
  2001.  
  2002.    The FC Entity uses Fibre Channel mechanisms for flow control at the
  2003.    FC Frame Receiver Portal based on information supplied by the FCIP
  2004.    Entity regarding flow constraints at the Encapsulated Frame
  2005.    Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow
  2006.    control at the Encapsulated Frame Receiver Portal portal based on
  2007.    information supplied by the FC Entity regarding flow constraints at
  2008.    the FC Frame Transmitter Portal.
  2009.  
  2010.    Coordination of these flow control mechanisms one of which is credit
  2011.    based and the other of which is window based depends on painstaking
  2012.    design that is outside the scope of this specification.
  2013.  
  2014. 10. Security
  2015.  
  2016. 10.1 Threat Models
  2017.  
  2018.    Using a general purpose, wide-area network such as an IP Network as
  2019.    a functional replacement for physical cabling introduces some
  2020.    security problems not normally encountered in Fibre Channel Fabrics.
  2021.    FC interconnect cabling typically is protected physically from
  2022.    outside access. Public IP Networks allow hostile parties to impact
  2023.    the security of the transport infrastructure.
  2024.  
  2025.    The general effect is that the security of an FC Fabric is only as
  2026.    good as the security of the entire IP Network that carries the FCIP
  2027.    Links used by that FC Fabric. The following broad classes of attacks
  2028.    are possible:
  2029.  
  2030.    1)  Unauthorized Fibre Channel elements can gain access to resources
  2031.        through normal Fibre Channel Fabric and processes. Although this
  2032.        is a valid threat, securing the Fibre Channel Fabrics is outside
  2033.  
  2034.  
  2035. Rajagopal, et al.               Standards Track                [Page 37]
  2036.  
  2037. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2038.  
  2039.  
  2040.        the scope of this document. Securing the IP Network is the issue
  2041.        considered in this specification.
  2042.  
  2043.    2)  Unauthorized agents can monitor and manipulate Fibre Channel
  2044.        traffic flowing over physical media used by the IP Network and
  2045.        accessible to the agent.
  2046.  
  2047.    3)  TCP Connections may be hijacked and used to instantiate an
  2048.        invalid FCIP Link between two peer FCIP Entities.
  2049.  
  2050.    4)  Valid and invalid FCIP Frames may be injected on the TCP
  2051.        Connections.
  2052.  
  2053.    5)  The payload of an FCIP Frame may be altered or transformed. The
  2054.        TCP checksum, FCIP ones complement checks and FC frame CRC do
  2055.        not protect against this because all of them can be modified or
  2056.        regenerated by a malicious and determined adversary.
  2057.  
  2058.    6)  Unauthorized agents can masquerade as a valid FCIP Entities and
  2059.        disturb proper operation of the Fibre Channel Fabric.
  2060.  
  2061.    7)  Denial of Service attacks can be mounted by injecting TCP
  2062.        Connection requests and other resource exhaustion operations.
  2063.  
  2064.    8)  An adversary may launch a variety of attacks against the
  2065.        discovery process [18].
  2066.  
  2067.    9)  An attacker may exploit the FSF authentication mechanism of the
  2068.        FCIP Link formation process (see section 9.1.3). The attacker
  2069.        could observe the FSF contents sent on an initial connection of
  2070.        an FCIP Link and use the observed nonce, Source FC/FCIP Entity
  2071.        Identifier and other FSF contents to form an FCIP Link using
  2072.        attacker's own previously established connection, while
  2073.        resetting/blocking the observed connection. Although the use of
  2074.        timeout for reception of FSF reduces the risk of this attack,
  2075.        such an attack is possible. See section 10.3.1 to protect
  2076.        against this specific attack.
  2077.  
  2078.    The existing IPsec Security Architecture and protocol suite [11]
  2079.    offers protection from these threats. An FCIP Entity MUST implement
  2080.    portions of the IPsec protocol suite as described in this section.
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089.  
  2090. Rajagopal, et al.               Standards Track                [Page 38]
  2091.  
  2092. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2093.  
  2094.  
  2095. 10.2 FC Fabric and IP Network Deployment Models
  2096.  
  2097.    In the context of enabling a secure FCIP tunnel between FC SANs, the
  2098.    following characteristics of the IP Network deployment are useful to
  2099.    note.
  2100.  
  2101.    1)  The FCIP Entities share a peer-to-peer relationship. Therefore,
  2102.        the administration of security policies applies to all FCIP
  2103.        Entities in an equal manner. This differs from a true Client-
  2104.        Server relationship, where there is an inherent difference in
  2105.        how security policies are administered.
  2106.  
  2107.    2)  Policy administration as well as security deployment and
  2108.        configuration are constrained to the set of FCIP Entities,
  2109.        thereby posing less of a requirement on a scalable mechanism.
  2110.        For example, the validation of credentials can be relaxed to the
  2111.        point where deploying a set of pre-shared keys is a viable
  2112.        technique.
  2113.  
  2114.    3)  TCP Connections and the IP Network are terminated at the FCIP
  2115.        Entity. The granularity of security implementation is at the
  2116.        level of the FCIP tunnel endpoint (or FCIP Entity), unlike other
  2117.        applications where there is a user-level termination of TCP
  2118.        Connections. User-level objects are not controllable by or
  2119.        visible to FCIP Entities. All user-level security related to
  2120.        FCIP is the responsibility of the Fibre Channel standards and
  2121.        outside the scope of this specification.
  2122.  
  2123. 10.3 FCIP Security Components
  2124.  
  2125.    FCIP Security compliant implementations MUST implement ESP and the
  2126.    IPsec Protocol Suite based cryptographic authentication and data
  2127.    integrity [11], as well as confidentiality using algorithms and
  2128.    transforms as described in this section. Also, FCIP implementations
  2129.    MUST meet the secure key management requirements of IPsec protocol
  2130.    suite.
  2131.  
  2132. 10.3.1 IPsec ESP Authentication and Confidentiality
  2133.  
  2134.    FCIP Entities MUST implement IPsec ESP [13] in Tunnel Mode for
  2135.    providing Data Integrity and Confidentiality. FCIP Entities MAY
  2136.    implement IPsec ESP in Transport Mode, if deployment considerations
  2137.    require use of Transport Mode. When ESP is utilized, per-packet data
  2138.    origin authentication, integrity and replay protection MUST be used.
  2139.  
  2140.    If Confidentiality is not enabled but Data Integrity is enabled, ESP
  2141.    with NULL Encryption [16] MUST be used.
  2142.  
  2143.  
  2144.  
  2145. Rajagopal, et al.               Standards Track                [Page 39]
  2146.  
  2147. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2148.  
  2149.  
  2150.    IPsec ESP for message authentication computes a cryptographic hash
  2151.    over the payload that is protected. While IPsec ESP mandates
  2152.    compliant implementations to support certain algorithms for deriving
  2153.    this hash, FCIP implementations:
  2154.  
  2155.     - MUST implement HMAC with SHA-1 [12]
  2156.     - SHOULD implement AES in CBC MAC mode with XCBC extensions [23]
  2157.     - DES in CBC mode SHOULD NOT be used due to inherent weaknesses
  2158.  
  2159.    For ESP Confidentiality, FCIP Entities:
  2160.  
  2161.     - MUST implement 3DES in CBC mode
  2162.     - SHOULD implement AES in CTR mode [22]
  2163.     - MUST implement NULL Encryption [16]
  2164.  
  2165.    When AES is used, the key size SHALL be at least 128-bits and the
  2166.    cipher block size SHALL be at least 128-bits.
  2167.  
  2168. 10.3.2 Key Management
  2169.  
  2170.    FCIP Entities MUST support IKE [15] for peer authentication,
  2171.    negotiation of Security Associations (SA) and Key Management using
  2172.    the IPsec DOI [14]. Manual keying SHALL NOT be used for establishing
  2173.    an SA since it does not provide the necessary elements for rekeying
  2174.    (see section 10.3.3). Conformant FCIP implementations MUST support
  2175.    peer authentication using pre-shared key and MAY support peer
  2176.    authentication using digital certificates. Peer authentication using
  2177.    public key encryption methods outlined in IKE [15] Section 5.2 and
  2178.    5.3 SHOULD NOT be used.
  2179.  
  2180.    IKE Phase 1 establishes a secure, MAC-authenticated channel for
  2181.    communications for use by IKE Phase 2. FCIP implementations MUST
  2182.    support IKE Main Mode and SHOULD support Aggressive Mode.
  2183.  
  2184.    FCIP Entities negotiate parameters for SA during IKE Phase 2 only
  2185.    using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode",
  2186.    there is no requirement for PFS (Perfect Forward Secrecy). FCIP
  2187.    Entities engaged in IKE "Quick Mode" are not required to transmit a
  2188.    Key Exchange (KE) payload. The Phase 2 Quick Mode exchanges MUST
  2189.    explicitly carry the Identity Payload fields (IDci and IDcr). Each
  2190.    Phase 2 payload SHOULD carry a single IP Address and a single non-
  2191.    zero port number and SHOULD NOT use the IP Subnet or IP Address
  2192.    Range formats. Other ID payload formats MUST NOT be used.
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200. Rajagopal, et al.               Standards Track                [Page 40]
  2201.  
  2202. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2203.  
  2204.  
  2205.    Since the number of Phase 2 SAs may be limited, Phase 2 delete
  2206.    messages may be sent for idle SAs. The receipt of a Phase 2 delete
  2207.    message SHOULD NOT be interpreted as a reason for tearing down an
  2208.    FCIP Link or any of its TCP connections. When there is new activity
  2209.    on that idle link, a new Phase 2 SA MUST be re-established.
  2210.  
  2211.    For a given pair of FCIP Entities, the same IKE Phase 1 negotiation
  2212.    can be used for all Phase 2 negotiations; i.e., all TCP Connections
  2213.    that are bundled into the single FCIP Link can share the same Phase
  2214.    1 results.
  2215.  
  2216.    Repeated rekeying using "Quick Mode" on the same shared secret will
  2217.    over time, reduce the cryptographic properties of that secret. To
  2218.    overcome this, Phase 1 SHOULD be invoked periodically to create a
  2219.    new set of IKE shared secrets and related security parameters.
  2220.  
  2221.    IKE Phase 1 establishment requires key distribution, and FCIP
  2222.    Entities:
  2223.  
  2224.     - MUST support pre-shared IKE keys.
  2225.     - MAY support certificate-based peer authentication using digital
  2226.       signatures.
  2227.     - Peer authentication using the public key encryption methods
  2228.       outlined in sections 5.2 and 5.3 of [15] SHOULD NOT be used.
  2229.  
  2230.    When pre-shared keys are used, IKE Main Mode is usable only when
  2231.    both peers of an FCIP Link use statically assigned IP addresses.
  2232.    When support for dynamically assigned IP Addresses is attempted in
  2233.    conjunction with Main Mode, use of group pre-shared keys would be
  2234.    forced, and the use of group pre-shared keys in combination with
  2235.    Main Mode is not recommended as it exposes the deployed environment
  2236.    for man-in-the-middle attacks. Therefore, if either peer of an FCIP
  2237.    Link uses dynamically assigned address, Aggressive Mode SHOULD be
  2238.    used and Main Mode SHOULD NOT be used.
  2239.  
  2240.    When Digital Signatures are used, either IKE Main Mode or IKE
  2241.    Aggressive Mode may be used. In all cases, access to locally stored
  2242.    secret information (pre-shared key, or private key for digital
  2243.    signing) MUST be suitably restricted, since compromise of secret
  2244.    information nullifies the security properties of IKE/IPsec
  2245.    protocols. Such mechanisms are outside the scope of this document.
  2246.    Support for IKE Oakley Groups [27] is not required.
  2247.  
  2248.    For the purposes of establishing a secure FCIP Link, the two
  2249.    participating FCIP Entities consult a Security Policy Database
  2250.    (SPD). The SPD is described in IPsec [11] Section 4.4.1. FCIP
  2251.    Entities may have more than one interface and IP Address, and it is
  2252.    possible for an FCIP Link to contain multiple TCP connections whose
  2253.  
  2254.  
  2255. Rajagopal, et al.               Standards Track                [Page 41]
  2256.  
  2257. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2258.  
  2259.  
  2260.    FCIP endpoint IP Addresses are different. In this case, an IKE Phase
  2261.    1 SA is established for each FCIP endpoint IP Address pair. Within
  2262.    IKE Phase 1, FCIP implementations must support the ID_IPV4_ADDR,
  2263.    ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN
  2264.    Identity Payloads. If FCIP Endpoint addresses are dynamically
  2265.    assigned, it may be beneficial to use ID_FQDN, and for this reason,
  2266.    IP_FQDN Identity Payload MUST be supported. Other identity payloads
  2267.    (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID) SHOULD NOT be used.
  2268.  
  2269.    At the end of successful IKE negotiations both FCIP Entities store
  2270.    the SA parameters in their SA database (SAD). The SAD is described
  2271.    in IPsec [11] Section 4.4.3. The SAD contains the set of active SA
  2272.    entries, each entry containing Sequence Counter Overflow, Sequence
  2273.    Number Counter, Anti-replay Window and the Lifetime of the SA. FCIP
  2274.    Entities SHALL employ a default SA Lifetime of one hour and a
  2275.    default Anti-replay window of 32 sequence numbers.
  2276.  
  2277.    When a TCP Connection is established between two FCIP_DEs, two
  2278.    unidirectional SAs are created for that connection and each SA is
  2279.    identified in the form of a Security Parameter Index (SPI). One SA
  2280.    is associated with the incoming traffic flow and the other SA is
  2281.    associated with the outgoing traffic flow. The FCIP_DEs at each end
  2282.    of the TCP connection MUST maintain the SPIs for both its incoming
  2283.    and outgoing FCIP Encapsulated Frames.
  2284.  
  2285.    FCIP Entities MAY provide administrative management of
  2286.    Confidentiality usage. These management interfaces SHOULD be
  2287.    provided in a secure manner, so as to prevent an attacker from
  2288.    subverting the security process by attacking the management interface.
  2289.  
  2290. 10.3.3 ESP Replay Protection and Rekeying issues
  2291.  
  2292.    FCIP Entities MUST implement Replay Protection against ESP Sequence
  2293.    Number wrap, as described in [15]. In addition, based on the cipher
  2294.    algorithm and the number of bits in the cipher block size, the
  2295.    validity of the key may become compromised. In both cases, the SA
  2296.    needs to be reestablished.
  2297.  
  2298.    FCIP Entities MUST use the results of IKE Phase 1 negotiation for
  2299.    initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs.
  2300.  
  2301.    To enable smooth transition of SAs, it is RECOMMENDED that both FCIP
  2302.    Entities refresh the SPI when sequence number counter reaches 2^31
  2303.    (i.e., half the sequence number space). It also is RECOMMENDED that
  2304.    the receiver operate with multiple SPIs for the same TCP Connection
  2305.    for a period of 2^31 sequence number packets before aging out an SPI.
  2306.  
  2307.  
  2308.  
  2309.  
  2310. Rajagopal, et al.               Standards Track                [Page 42]
  2311.  
  2312. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2313.  
  2314.  
  2315.    When a new SPI is created for the outgoing direction, the sending
  2316.    side SHALL begin using it for all new FCIP Encapsulated Frames.
  2317.    Frames that are either in-flight, or resent due to TCP
  2318.    retransmissions etc. MAY use either the new SPI or the one being
  2319.    replaced.
  2320.  
  2321. 10.4 Secure FCIP Link Operation
  2322.  
  2323. 10.4.1 FCIP Link Initialization Steps
  2324.  
  2325.    When an FCIP Link is initialized, before any FCIP TCP Connections
  2326.    are established, the local SPD is consulted to determine if IKE
  2327.    Phase 1 has been completed with the FCIP Entity in the peer FCIP
  2328.    Entity, as identified by the WWN.
  2329.  
  2330.    If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise,
  2331.    IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE
  2332.    Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1
  2333.    fails, the FCIP Link initialization terminates. Otherwise, the FCIP
  2334.    Link initialization moves to TCP Connection Initialization.
  2335.  
  2336.    As described in section 9.1, FCIP Entities exchange an FSF, for
  2337.    forming an FCIP Link. The use of ESP Confidentiality is an effective
  2338.    countermeasure against any perceived security risks of FSF.
  2339.  
  2340. 10.4.2 TCP Connection Security Associations (SAs)
  2341.  
  2342.    Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic
  2343.    from one or more than one TCP connection may flow within each IPsec
  2344.    Phase 2 SA. While it is possible for a IKE Phase 2 SA to protect
  2345.    multiple TCP connections, all packets of a TCP connection is
  2346.    protected using only one IKE Phase 2 SA. FCIP implementations need
  2347.    not verify that the IP addresses and port numbers in the packet
  2348.    match any locally stored per-connection values, leaving this check
  2349.    to be performed by the IPsec layer."
  2350.  
  2351.    An implementation is free to perform several IKE Phase 2
  2352.    negotiations and cache them in its local SPIs, although entries in
  2353.    such a cache can be flushed per current SA Lifetime settings.
  2354.  
  2355. 10.4.3 Handling data integrity and confidentiality violations
  2356.  
  2357.    Upon datagram reception, when the ESP packet fails an integrity
  2358.    check, the receiver MUST drop the datagram, which will trigger TCP
  2359.    retransmission. If many such datagrams are dropped, a receiving FCIP
  2360.    Entity MAY close the TCP Connection and notify the FC Entity with
  2361.    the reason for the closure.
  2362.  
  2363.  
  2364.  
  2365. Rajagopal, et al.               Standards Track                [Page 43]
  2366.  
  2367. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2368.  
  2369.  
  2370.    An implementation SHOULD follow guidelines for auditing all
  2371.    auditable ESP events per IPsec [11] Section 7.
  2372.  
  2373.    Integrity checks MUST be performed if Confidentiality is enabled.
  2374.  
  2375. 11. Performance
  2376.  
  2377. 11.1 Performance Considerations
  2378.  
  2379.    Traditionally, the links between FC Fabric components have been
  2380.    characterized by low latency and high throughput. The purpose of
  2381.    FCIP is to provide functionality equivalent to these links using an
  2382.    IP Network, where low latency and high throughput are not as
  2383.    certain. It follows that FCIP Entities and their counterpart FC
  2384.    Entities probably will be interested in optimal use of the IP Network.
  2385.  
  2386.    Many options exist for ensuring high throughput and low latency
  2387.    appropriate for the distances involved in an IP Network. For
  2388.    example, a private IP Network might be constructed for the sole use
  2389.    of FCIP Entities. The options that are within the scope of this
  2390.    specification are discussed here.
  2391.  
  2392.    One option for increasing the probability that FCIP data streams
  2393.    will experience low latency and high throughput is the IP QoS
  2394.    techniques discussed in section 11.2. This option can have value
  2395.    when applied to a single TCP Connection. Depending on the
  2396.    sophistication of the FC Entity, further value may be obtained by
  2397.    having multiple TCP Connections with differing QoS characteristics.
  2398.  
  2399.    There are many reasons why an FC Entity might request creation of
  2400.    multiple TCP Connections within an FCIP_LEP. These reasons include a
  2401.    desire to provide differentiated service for different TCP data
  2402.    connections between FCIP_LEPs or a preference to separately queue
  2403.    different streams of traffic not having a common in-order delivery
  2404.    requirement.
  2405.  
  2406.    At the time a new TCP Connection is created, the FC Entity SHALL
  2407.    specify to the FCIP Entity the QoS characteristics (including but
  2408.    not limited to IP per-hop-behavior) to be used for the lifetime of
  2409.    that connection. This MAY be achieved by having:
  2410.    a)  only one set of QoS characteristics for all TCP Connections;
  2411.    b)  a default set of QoS characteristics that the FCIP Entity
  2412.        applies in the absence of differing instructions from the FC
  2413.        Entity; or
  2414.    c)  a sophisticated mechanism for exchanging QoS requirements
  2415.        information between the FC Entity and FCIP Entity each time a
  2416.        new TCP Connection is created.
  2417.  
  2418.  
  2419.  
  2420. Rajagopal, et al.               Standards Track                [Page 44]
  2421.  
  2422. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2423.  
  2424.  
  2425.    Once established, the QoS characteristics of a TCP Connection SHALL
  2426.    NOT be changed, since this specification provides no mechanism for
  2427.    the FC Entity to control such changes. The mechanism for providing
  2428.    different QoS characteristics in FCIP is the establishment of a
  2429.    different TCP Connections and associated FCIP_DEs.
  2430.  
  2431.    When FCIP is used with a network with a large (bandwidth*delay)
  2432.    product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms
  2433.    (window scaling and wrapped sequence protection) for Long Fat
  2434.    Networks (LFNs) as defined in RFC 1323 [24].
  2435.  
  2436. 11.2 IP Quality of Service (QoS) Support
  2437.  
  2438.    Many methods of providing QoS have been devised or proposed. These
  2439.    include (but are not limited to) the following:
  2440.  
  2441.     - Multi-Protocol Label Switching (MPLS)
  2442.     - Differentiated Services Architecture (diffserv) -- RFC 2474
  2443.       [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and
  2444.       other forms of per-hop-behavior (PHB)
  2445.     - Integrated Services, RFC 1633 [25]
  2446.     - IEEE 802.1p
  2447.  
  2448.    The purpose of this specification is not to specify any particular
  2449.    form of IP QoS but rather to specify only those issues that must be
  2450.    addressed in order to maximize interoperability between FCIP
  2451.    equipment that has been manufactured by different vendors.
  2452.  
  2453.    It is RECOMMENDED that some form of preferential QoS be used for
  2454.    FCIP traffic to minimize latency and packet drops. No particular
  2455.    form of QoS is recommended.
  2456.  
  2457.    If a PHB IP QoS is implemented, it is RECOMMENDED that it
  2458.    interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC
  2459.    2597 [30], and RFC 2598 [31]).
  2460.  
  2461.    If no form of preferential QoS is implemented, the DSCP field SHOULD
  2462.    be set to '000000' to avoid negative impacts on other network
  2463.    components and services that may be caused by uncontrolled usage of
  2464.    non-zero values of the DSCP field.
  2465.  
  2466.  
  2467.  
  2468.  
  2469.  
  2470.  
  2471.  
  2472.  
  2473.  
  2474.  
  2475. Rajagopal, et al.               Standards Track                [Page 45]
  2476.  
  2477. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2478.  
  2479.  
  2480. 12. Normative References
  2481.  
  2482.    The references in this section were current as of the time this
  2483.    specification was approved. This specification is intended to
  2484.    operate with newer version of the referenced documents and looking
  2485.    for newer reference documents is recommended.
  2486.  
  2487.    [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
  2488.        9, RFC 2026, October 1996.
  2489.  
  2490.    [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  2491.        Levels", BCP 14, RFC 2119, March 1997.
  2492.  
  2493.    [3] Fibre Channel Backbone (FC-BB), ANSI NCITS.342:200x, March 5,
  2494.        2001 (http://www.t11.org/t11/docreg.nsf/ldl/fc-bb).
  2495.  
  2496.    [4] Fibre Channel Backbone -2 (FC-BB-2), T11 Project 1466-D, (http://
  2497.        www.t11.org/t11/docreg.nsf/ldl/fc-bb-2).
  2498.  
  2499.    [5] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:200x,
  2500.        May 23, 2001 (http://www.t11.org/t11/docreg.nsf/ldl/fc-sw-2).
  2501.  
  2502.    [6] Fibre Channel Framing and Signaling (FC-FS), T11 Project 1331-D,
  2503.        Rev 1.2, February 16, 2001 (http://www.t11.org/t11/docreg.nsf/
  2504.        ldl/fc-fs).
  2505.  
  2506.    [7] "Transmission Control Protocol", RFC 793, Sept. 1981.
  2507.  
  2508.    [8] Braden, R., "Requirements for Internet Hosts -- Communication
  2509.        Layers", RFC 1122, October 1989
  2510.  
  2511.    [9] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions for
  2512.        High Performance", RFC 1323, May 1992
  2513.  
  2514.    [10] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
  2515.        Recommendations for Security", RFC 1750, Dec. 1994.
  2516.  
  2517.    [11] Kent, S. and Atkinson, R., "Security Architecture for the
  2518.        Internet Protocol", RFC 2401, Nov. 1998.
  2519.  
  2520.    [12] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed-
  2521.        Hashing for Message Authentication", RFC 2104, February 1997.
  2522.  
  2523.    [13] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload
  2524.        (ESP)", RFC 2406, Nov. 1998.
  2525.  
  2526.    [14] Piper, D., "The Internet IP Security Domain of Interpretation
  2527.        of ISAKMP", RFC 2407, November 1998.
  2528.  
  2529.  
  2530. Rajagopal, et al.               Standards Track                [Page 46]
  2531.  
  2532. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2533.  
  2534.  
  2535.  
  2536.    [15] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
  2537.        RFC 2409, November 1998.
  2538.  
  2539.    [16] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use
  2540.        With IPsec", RFC 2410, Nov. 1998
  2541.  
  2542.    [17] Thayer, R., Glenn, R., and Doraswamy, N., "IP Security Document
  2543.        Roadmap", RFC 2411, Nov. 1998.
  2544.  
  2545.    [18] E.Guttman, C. Perkins, J. Veizades, M. Day. Service Location
  2546.        Protocol, version 2, RFC 2608, July, 1999.
  2547.  
  2548.    [19] Floyd, et al, "SACK Extension", RFC 2883, July 2000.
  2549.  
  2550.    [20] Weber, Rajagopal, Travostino, Chau, O'Donnell, Monia Merhar,
  2551.        "FC Frame Encapsulation", draft-ietf-ips-fcencapsulation-__.txt
  2552.        (RFC reference and date to be added during standards action).
  2553.  
  2554.    [21] Peterson, "Finding FCIP Entities Using SLP", draft-ietf-ips-
  2555.        fcip-slp-___.txt (RFC reference and date to be added during
  2556.        standards action).
  2557.  
  2558.    [22] Walker, J., Moskowitz, R., "The AES128 CTR Mode of Operation
  2559.        and Its Use with IPsec", Internet draft (work in progress),
  2560.        draft-moskowitz-aes128-ctr-00.txt, September 2001.
  2561.  
  2562.    [23] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm  
  2563.        and Its Use with IPsec", Internet draft (work in progress),
  2564.        draft-ietf-ipsec-ciph-aes-cbc-01.txt, May 2001.
  2565.  
  2566.  
  2567. 13. Informative References
  2568.  
  2569.    The following references may prove informative to readers unfamiliar
  2570.    with Fibre Channel.
  2571.  
  2572.    [24] Jacobson, V., Braden, R. and Borman, D., "TCP Extensions for
  2573.        High Performance", RFC 1323, May 1992.
  2574.  
  2575.    [25] R. Braden, et. al., ISI, "Integrated Services in the Internet
  2576.        Architecture: an Overview", RFC 1633, June 1994
  2577.  
  2578.    [26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
  2579.        IPv4, IPv6 and OSI", RFC 2030, October 1996.
  2580.  
  2581.    [27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
  2582.        November 1998.
  2583.  
  2584.  
  2585. Rajagopal, et al.               Standards Track                [Page 47]
  2586.  
  2587. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2588.  
  2589.  
  2590.  
  2591.    [28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
  2592.        the Differentiated Services Field (DS Field) in the IPv4 and
  2593.        Ipv6 Headers", RFC 2474, December 1998.
  2594.  
  2595.    [29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss,
  2596.        W., "An Architecture for Differentiated Services", RFC 2475,
  2597.        Dec. 1998.
  2598.  
  2599.    [30] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "An Assured
  2600.        Forwarding PHB", RFC 2597, June 1999.
  2601.  
  2602.    [31] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding
  2603.        PHB Group", RFC 2598, June 1999.
  2604.  
  2605.    [32] Rosen, E., A. Viswanathan, A., and Callon, R., "Multiprotocol
  2606.        Label Switching Architecture", RFC 3031, January, 2001.
  2607.  
  2608.    [33] Kembel, R., "The Fibre Channel Consultant: A Comprehensive
  2609.        Introduction", Northwest Learning Associates, 1998
  2610.  
  2611.  
  2612. 14. Acknowledgments
  2613.  
  2614.    The developers of this specification thank Mr. Jim Nelson for his
  2615.    assistance with FC-FS related issues.
  2616.  
  2617.    The developers of this specification express their appreciation to
  2618.    Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed
  2619.    and helpful reviews.
  2620.  
  2621.    Funding for the RFC Editor function is currently provided by the
  2622.    Internet Society.
  2623.  
  2624.  
  2625. 15. Contributors' Addresses
  2626.  
  2627.    Murali Rajagopal                   Vi Chau
  2628.    SV Systems                         USA
  2629.    518 Valley Way                     Email: vchau1@cox.net
  2630.    Milpitas, CA 95035
  2631.    USA
  2632.    Phone: +1 949 280 6516
  2633.    Email: muralir@cox.net
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640. Rajagopal, et al.               Standards Track                [Page 48]
  2641.  
  2642. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2643.  
  2644.  
  2645.    Elizabeth G. Rodriguez             Neil Wanamaker
  2646.    USA                                Akara
  2647.    Phone: +1 214 495 8712             10624 Icarus Court
  2648.    Fax: +1 214 495 8712               Austin, TX 78726
  2649.    Email:                             USA
  2650.        ElizabethRodriguez@ieee.org    Phone: +1 512 257 7633
  2651.                                       Fax: +1 512 257 7877
  2652.                                       Email: nwanamaker@akara.com
  2653.  
  2654.    Ralph Weber                        Steve Wilson
  2655.    ENDL Texas, representing Brocade   Brocade Comm. Systems, Inc.
  2656.    Suite 102 PMB 178                  1745 Technology Drive
  2657.    18484 Preston Road                 San Jose, CA. 95110
  2658.    Dallas, TX 75252                   USA
  2659.    USA                                Phone: +1 408 487 8128
  2660.    Phone: +1 214 912 1373             Fax: +1 408 487 8101
  2661.    Email: roweber@acm.org             email: swilson@brocade.com
  2662.  
  2663.    Bob Snively                        David Peterson
  2664.    Brocade Comm. Systems, Inc.        Cisco Systems - SRBU
  2665.    1745 Technology Drive              6450 Wedgwood Road
  2666.    San Jose, CA 95110                 Maple Grove, MN 55311
  2667.    USA                                USA
  2668.    Phone: +1 408 487 8135             Phone: +1 763 398 1007
  2669.    Email: rsnively@brocade.com        Cell: +1 612 802 3299
  2670.                                       Email: dap@cisco.com
  2671.  
  2672.    Donald R. Fraser                   R. Andy Helland
  2673.    Hewlett-Packard                    LightSand Communications, Inc.
  2674.    301 Rockrimmon Blvd., Bldg. 5      375 Los Coches Street
  2675.    Colorado Springs, CO 80919         Milpitas, CA 95035
  2676.    USA                                USA
  2677.    Phone: +1 719 548 3272             Phone: +1 408 404 3119
  2678.    Email: Don.Fraser@HP.com           Fax: +1 408 941 2166
  2679.                                       Email: andyh@lightsand.com
  2680.  
  2681.    Raj Bhagwat                        Bill Krieg
  2682.    LightSand Communications, Inc.     Lucent Technologies
  2683.    24411 Ridge Route Dr.              200 Lucent Lane
  2684.    Suite 135                          Cary, NC 27511
  2685.    Laguna Hills, CA 92653             USA
  2686.    USA                                Phone: +1 919 463 4020
  2687.    Phone: +1 949 837 1733 x104        Fax: +1 919 463 4041
  2688.    Email: rajb@lightsand.com          Email: bkrieg@lucent.com
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694.  
  2695. Rajagopal, et al.               Standards Track                [Page 49]
  2696.  
  2697. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2698.  
  2699.  
  2700.    Michael E. O'Donnell               Anil Rijhsinghani
  2701.    McDATA Corporation                 McDATA Corporation
  2702.    310 Interlocken Parkway            5 Brickyard lane
  2703.    Broomfield, Co. 80021              Westboro, MA 01581
  2704.    USA                                USA
  2705.    Phone: +1 303 460 4142             Phone: +1 508 870 6593
  2706.    Fax: +1 303 465 4996               Email:
  2707.    Email: modonnell@mcdata.com            anil.rijhsinghani@mcdata.com
  2708.  
  2709.    Milan J. Merhar                    Craig W. Carlson
  2710.    43 Nagog Park                      QLogic Corporation
  2711.    Pirus Networks                     6321 Bury Drive
  2712.    Acton, MA 01720                    Eden Prairie, MN 55346
  2713.    USA                                USA
  2714.    Phone: +1 978 206 9124             Phone: +1 952 932 4064
  2715.    Email: Milan@pirus.com             Email: craig.carlson@qlogic.com
  2716.  
  2717.    Venkat Rangan                      Lawrence J. Lamers
  2718.    Rhapsody Networks Inc.             SAN Valley Systems, Inc.
  2719.    3450 W. Warren Ave.                6320 San Ignacio Ave.
  2720.    Fremont, CA 94538                  San Jose, CA 95119-1209
  2721.    USA                                USA
  2722.    Phone: +1 510 743 3018             Phone: +1 408 234 0071
  2723.    Fax: +1 510 687 0136               Email: ljlamers@ieee.org
  2724.    Email: venkat@rhapsodynetworks.com
  2725.  
  2726.    Ken Hirata
  2727.    Vixel Corporation
  2728.    15245 Alton Parkway, Suite 100
  2729.    Irvine, CA 92618
  2730.    USA
  2731.    Phone: +1 949 788 6368
  2732.    Fax: +1 949 753 9500
  2733.    Email: ken.hirata@vixel.com
  2734.  
  2735.  
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744.  
  2745.  
  2746.  
  2747.  
  2748.  
  2749.  
  2750. Rajagopal, et al.               Standards Track                [Page 50]
  2751.  
  2752. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2753.  
  2754.  
  2755. 16. Full Copyright Statement
  2756.  
  2757.    Copyright (C) The Internet Society (2002). All Rights Reserved.
  2758.  
  2759.    This document and translations of it may be copied and furnished to
  2760.    others, and derivative works that comment on or otherwise explain it
  2761.    or assist in its implementation may be prepared, copied, published
  2762.    and distributed, in whole or in part, without restriction of any
  2763.    kind, provided that the above copyright notice and this paragraph
  2764.    are included on all such copies and derivative works. However, this
  2765.    document itself may not be modified in any way, such as by removing
  2766.    the copyright notice or references to the Internet Society or other
  2767.    Internet organizations, except as needed for the purpose of
  2768.    developing Internet standards in which case the procedures for
  2769.    copyrights defined in the Internet Standards process must be
  2770.    followed, or as required to translate it into languages other than
  2771.    English.
  2772.  
  2773.    The limited permissions granted above are perpetual and will not be
  2774.    revoked by the Internet Society or its successors or assigns.
  2775.  
  2776.    This document and the information contained herein is provided on an
  2777.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2778.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2779.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2780.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2781.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2782.  
  2783.  
  2784. APPENDIX A - Fibre Channel Bit and Byte Numbering Guidance
  2785.  
  2786.    Both Fibre Channel and IETF standards use the same byte transmission
  2787.    order. However, the bit and byte numbering is different.
  2788.  
  2789.    Fibre Channel bit and byte numbering can be observed if the data
  2790.    structure heading shown in figure 11, is cut and pasted at the top
  2791.    of figure 7, figure 9, and figure 17.
  2792.  
  2793.     W|------------------------------Bit------------------------------|
  2794.     o|                                                               |
  2795.     r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
  2796.     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|
  2797.  
  2798.        Fig. 11  Fibre Channel Data Structure Bit and Byte Numbering
  2799.  
  2800.    Fibre Channel bit numbering for the pFlags field can be observed
  2801.    if the data structure heading shown in figure 12, is cut and
  2802.    pasted at the top of figure 8.
  2803.  
  2804.  
  2805. Rajagopal, et al.               Standards Track                [Page 51]
  2806.  
  2807. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2808.  
  2809.  
  2810.  
  2811.        |----------------Bit--------------------|
  2812.        |                                       |
  2813.        | 31   30   29   28   27   26   25   24 |
  2814.  
  2815.        Fig. 12  Fibre Channel pFlags Bit Numbering
  2816.  
  2817.    Fibre Channel bit numbering for the Connection Usage Flags field can
  2818.    be observed if the data structure heading shown in figure 13, is cut
  2819.    and pasted at the top of figure 10.
  2820.  
  2821.    |------------------------------Bit------------------------------|
  2822.    |                                                               |
  2823.    |   31      30      29      28      27      26      25      24  |
  2824.  
  2825.        Fig. 13  Fibre Channel Connection Usage Flags Bit Numbering
  2826.  
  2827.  
  2828. APPENDIX B - IANA Considerations
  2829.  
  2830.    IANA has made the following port assignments to FCIP:
  2831.  
  2832.     - fcip-port 3225/tcp FCIP
  2833.     - fcip-port 3225/udp FCIP
  2834.  
  2835.    IANA is instruct to change the authority for these port allocations
  2836.    to reference this RFC when it is approved.
  2837.  
  2838.    Use of UDP with FCIP is prohibited even though IANA has allocated a
  2839.    port.
  2840.  
  2841.    The FC Frame encapsulation used by this specification employs
  2842.    Protocol# value 1, as described in the IANA Considerations appendix
  2843.    of the FC Frame Encapsulation [20] specification.
  2844.  
  2845.  
  2846. APPENDIX C - FCIP Usage of Addresses and Identifiers
  2847.  
  2848.    In support of network address translators, FCIP does not use IP
  2849.    Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP
  2850.    Addresses for identification occurs when initiating new TCP connect
  2851.    requests (see section 9.1.2.3) where the IP Address destination of
  2852.    the TCP connect request is used to answer the question: "Have
  2853.    previous TCP connect requests been made to the same destination FCIP
  2854.    Entity?" The correctness of this assumption is further checked by
  2855.    sending the Destination FC Fabric Entity World Wide Name in the FCIP
  2856.    Special Frame (FSF) and having the value checked by the FCIP Entity
  2857.    that receives the TCP connect request and FSF (see section 9.1.3).
  2858.  
  2859.  
  2860. Rajagopal, et al.               Standards Track                [Page 52]
  2861.  
  2862. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2863.  
  2864.  
  2865.  
  2866.    For the purposes of processing incoming TCP connect requests, the
  2867.    source FCIP Entity is identified by the Source FC Fabric Entity
  2868.    World Wide Name and Source FC/FCIP Entity Identifier fields in the
  2869.    FSF sent from the TCP connect requestor to the TCP connect recipient
  2870.    as the first bytes following the TCP connect request (see section
  2871.    9.1.2.3 and section 9.1.3).
  2872.  
  2873.    FC-BB-2 [4] provides the definitions for each of the following FSF
  2874.    fields:
  2875.  
  2876.     - Source FC Fabric Entity World Wide Name,
  2877.     - Source FC/FCIP Entity Identifier, and
  2878.     - Destination FC Fabric Entity World Wide Name.
  2879.  
  2880.    As described in section 9.1.3, FCIP Entities segregate their
  2881.    FCIP_LEPs between:
  2882.     - Connections resulting from TCP connect requests initiated by the
  2883.       FCIP Entity, and
  2884.     - Connections resulting from TCP connect requests received by the
  2885.       FCIP Entity.
  2886.  
  2887.    Within each of these two groups, the following information is used
  2888.    to further identify each FCIP_LEP:
  2889.  
  2890.     - Source FC Fabric Entity World Wide Name,
  2891.     - Source FC/FCIP Entity Identifier, and
  2892.     - Destination FC Fabric Entity World Wide Name.
  2893.  
  2894.  
  2895. APPENDIX D - Example of synchronization recovery algorithm
  2896.  
  2897.    The contents of this annex are informative.
  2898.  
  2899.    Synchronization may be recovered as specified in section 6.6.2.3. An
  2900.    example of an algorithm for searching the bytes delivered to the
  2901.    Encapsulated Frame Receiver Portal for a valid FCIP Frame header is
  2902.    provided in this annex.
  2903.  
  2904.    This resynchronization uses the principle that a valid FCIP data
  2905.    stream must contain at least one valid header every 2176 bytes (the
  2906.    maximum length of an encapsulated FC Frame). Although other data
  2907.    patterns containing apparently valid headers may be contained in the
  2908.    stream, the FC CRC or FCIP Frame validity of the data patterns
  2909.    contained in the data stream will always be either interrupted by or
  2910.    resynchronized with the valid FCIP Frame headers.
  2911.  
  2912.  
  2913.  
  2914.  
  2915. Rajagopal, et al.               Standards Track                [Page 53]
  2916.  
  2917. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2918.  
  2919.  
  2920.    Consider the case shown in figure 14. A series of short FCIP Frames,
  2921.    perhaps from a trace, are embedded in larger FCIP Frames, say as a
  2922.    result of a trace file being transferred from one disk to another.
  2923.    The headers for the short FCIP Frames are denoted SFH and the long
  2924.    FCIP Frame headers are marked as LFH.
  2925.  
  2926.        +-+--+-+----+-+----+-+----+-+-+-+---+-+---
  2927.        |L|  |S|    |S|    |S|    |S| |L|   |S|
  2928.        |F|  |F|    |F|    |F|    |F| |F|   |F|...
  2929.        |H|  |H|    |H|    |H|    |H| |H|   |H|
  2930.        +-+--+-+----+-+----+-+----+-+-+-+---+-+---
  2931.        |                             |
  2932.        |<---------2176 bytes-------->|
  2933.  
  2934.        Fig. 14  Example of resynchronization data stream
  2935.  
  2936.    A resynchronization attempt that starts just to the right of an LFH
  2937.    will find several SFH FCIP Frames before discovering that they do
  2938.    not represent the transmitted stream of FCIP Frames. Within 2176
  2939.    bytes plus or minus, however, the resynchronization attempt will
  2940.    encounter an SFH whose length does not match up with the next SFH
  2941.    because the LFH will fall in the middle of the short FCIP Frame
  2942.    pushing the next header farther out in the byte stream.
  2943.  
  2944.    Note that the resynchronization algorithm cannot forward any
  2945.    prospective FC Frames to the FC Frame Transmitter Portal because
  2946.    until synchronization is completely established there is no
  2947.    certainty that anything that looked like an FCIP Frame really was
  2948.    one. For example, an SFH might fortuitously contain a length that
  2949.    points exactly to the beginning of an LFH. The LFH would identify
  2950.    the correct beginning of a transmitted FCIP Frame, but that in no
  2951.    way guarantees that the SFH was also a correct FCIP Frame header.
  2952.  
  2953.    There exist some data streams that cannot be resynchronized by this
  2954.    algorithm. If such a data stream is encountered, the algorithm
  2955.    causes the TCP Connection to be closed.
  2956.  
  2957.    The resynchronization assumes that security and authentication
  2958.    procedures outside the FCIP Entity are protecting the valid data
  2959.    stream from being replaced by an intruding data stream containing
  2960.    valid FCIP data.
  2961.  
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970. Rajagopal, et al.               Standards Track                [Page 54]
  2971.  
  2972. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  2973.  
  2974.  
  2975.    The following steps are one example of how an FCIP_DE might
  2976.    resynchronize with the data stream entering the Encapsulated Frame
  2977.    Receiver Portal.
  2978.  
  2979.    1)  Search for candidate and strong headers:
  2980.  
  2981.        The data stream entering the Encapsulated Frame Receiver Portal
  2982.        is searched for 12 bytes in a row containing the required values
  2983.        for:
  2984.        a)  Protocol field,
  2985.        b)  Version field,
  2986.        c)  ones complement of the Protocol field,
  2987.        d)  ones complement of the Version field,
  2988.        e)  replication of encapsulation word 0 in word 1, and 
  2989.        f)  pFlags field and its ones complement.
  2990.  
  2991.        If such a 12-byte grouping is found, the FCIP_DE assumes that it
  2992.        has identified bytes 0-2 of a candidate FCIP encapsulation header.
  2993.  
  2994.        All bytes up to and including the candidate header byte are
  2995.        discarded.
  2996.  
  2997.        If no candidate header has been found after searching a
  2998.        specified number of bytes greater than some multiple of 2176
  2999.        (the maximum length of an FCIP Frame), resynchronization has
  3000.        failed and the TCP/IP connection is closed.
  3001.  
  3002.        Word 3 of the candidate header contains the Frame Length and
  3003.        Flags fields and their ones complements. If the fields are
  3004.        consistent with their ones complements, the candidate header is
  3005.        considered a strong candidate header. The Frame Length field is
  3006.        used to determine where in byte stream the next strong candidate
  3007.        header should be and processing continues at step 2).
  3008.  
  3009.    2)  Use multiple strong candidate headers to locate a verified
  3010.        candidate header:
  3011.  
  3012.        The Frame Length in one strong candidate header is used to skip
  3013.        incoming bytes until the expected location of the next strong
  3014.        candidate header is reached. Then the tests described in step 1)
  3015.        are applied to see if another strong candidate header has
  3016.        successfully been located.
  3017.  
  3018.        All bytes skipped and all bytes in all strong candidate headers
  3019.        processed are discarded.
  3020.  
  3021.        Strong candidate headers continue to be verified in this way for
  3022.        at least 4352 bytes (twice the maximum length of an FCIP Frame).
  3023.  
  3024.  
  3025. Rajagopal, et al.               Standards Track                [Page 55]
  3026.  
  3027. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3028.  
  3029.  
  3030.        If at any time a verification test fails, processing restarts at
  3031.        step 1 and a retry counter is incremented. If the retry counter
  3032.        exceeds 3 retries, resynchronization has failed and the TCP
  3033.        Connection is closed.
  3034.  
  3035.        After strong candidate headers haves been verified for at least
  3036.        4352 bytes, the next header identified is a verified candidate
  3037.        header and processing continues at step 3).
  3038.  
  3039.        Note: If a strong candidate header was part of the data content
  3040.        of an FCIP Frame, the FCIP Frame defined by that or a subsequent
  3041.        strong candidate header will eventually cross an actual header
  3042.        in the byte stream. As a result it will either identify the
  3043.        actual header as a strong candidate header or it will lose
  3044.        synchronization again because of the extra 28 bytes in the
  3045.        length, returning to step 1 as described above.
  3046.  
  3047.    3)  Use multiple strong candidate headers to locate a verified
  3048.        candidate header:
  3049.  
  3050.        Incoming bytes are inspected and discarded until the next
  3051.        verified candidate header is reached. Inspection of the incoming
  3052.        bytes includes testing for other candidate headers using the
  3053.        criteria described in step 1. Each verified candidate header is
  3054.        tested against the tests listed in section 6.6.2.2 as would
  3055.        normally be the case.
  3056.  
  3057.        Verified candidate headers continue to be located and tested in
  3058.        this way for a minimum of 4352 bytes (twice the maximum length
  3059.        of an FCIP Frame). If all verified candidate headers encountered
  3060.        are valid, the last verified candidate header is a valid header.
  3061.        At this point the FCIP_DE stops discarding bytes and begins
  3062.        normal FCIP de-encapsulation begins, including for the first
  3063.        time since synchronization was lost, delivery of FC Frames
  3064.        through the FC Frame Transmitter Portal according to normal FCIP
  3065.        rules.
  3066.  
  3067.        If any verified candidate headers are invalid but meet all the
  3068.        requirements of a strong candidate header, increment the retry
  3069.        counter and return to step 2). If any verified candidate headers
  3070.        are invalid and fail to meet the tests for a strong candidate
  3071.        header or if inspection of the bytes between verified candidate
  3072.        headers discovers any candidate headers, increment the retry
  3073.        counter and return to step 1. If the retry counter exceeds 4
  3074.        retries, resynchronization has failed and the TCP/IP connection
  3075.        is closed.
  3076.  
  3077.    A flowchart for this algorithm can be found in figure 15.
  3078.  
  3079.  
  3080. Rajagopal, et al.               Standards Track                [Page 56]
  3081.  
  3082. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3083.  
  3084.  
  3085.  
  3086.                          Synchronization is lost
  3087.                                   |
  3088.                      _____________v_______________
  3089.                     |                             |
  3090.                     | Search for candidate header |
  3091.        +----------->|                             |
  3092.        |            |   Found           Not Found |
  3093.        |            | (Strong candidate)          |
  3094.        |            |_____________________________|
  3095.        |                    |              |
  3096.        |                    |              + --------->close TCP
  3097.        |             _______v_____________________     Connection
  3098.        |            |                             |    and notify
  3099.        |            |   Enough strong candidate   |    the FC Entity
  3100.        |      +---->|     headers identified?     |    with the reason
  3101.        |      |     |                             |    for closure
  3102.        |      |     |     No               Yes    |
  3103.        |      |     |        (Verified candidate) |
  3104.        |      |     |_____________________________|
  3105.        |___________________|                |
  3106.        ^      |                             |
  3107.        |      |                             |
  3108.        |      |      _______________________v_____
  3109.        |      |     |                             |
  3110.        |      |     | Enough verified candidate   |
  3111.        |      |     |   headers validated?        |
  3112.        |      |     |                             |
  3113.        |      |     |     No               Yes    |
  3114.        |      |     |            (Resynchronized) |
  3115.        |      |     |_____________________________|
  3116.        |      |            |                |
  3117.        |      |      ______v__________      |      Resume
  3118.        |      |     |                 |     + ---> Normal
  3119.        |      |     | Synchronization |            De-encapsulation
  3120.        |      |     |      Lost?      |
  3121.        |      |     |                 |
  3122.        |      |     | No          Yes |
  3123.        |      |     |_________________|
  3124.        |      |        |           |
  3125.        |      |________|           |
  3126.        |___________________________|
  3127.  
  3128.        Fig. 15  Flow diagram of simple synchronization example
  3129.  
  3130.  
  3131.  
  3132.  
  3133.  
  3134.  
  3135. Rajagopal, et al.               Standards Track                [Page 57]
  3136.  
  3137. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3138.  
  3139.  
  3140.  
  3141. APPENDIX E - Relationship between FCIP and IP over FC (IPFC)
  3142.  
  3143.    The contents of this annex are informative.
  3144.  
  3145.    IPFC (RFC 2625) describes the encapsulation of IP packets in FC
  3146.    Frames. It is intended to facilitate IP communication over an FC
  3147.    network.
  3148.  
  3149.    FCIP describes the encapsulation of FC Frames in TCP segments which
  3150.    in turn are encapsulated inside IP packets for transporting over an
  3151.    IP network. It gives no consideration to the type of FC Frame that
  3152.    is being encapsulated. Therefore, the FC Frame may actually contain
  3153.    an IP packet as described in the IP over FC specification (RFC
  3154.    2625). In such a case, the data packet would have:
  3155.  
  3156.     - Data Link Header
  3157.     - IP Header
  3158.     - TCP Header
  3159.     - FCIP Header
  3160.     - FC Header
  3161.     - IP Header
  3162.  
  3163.    Note:   The two IP headers would not be identical to each other. One
  3164.    would have information pertaining to the final destination while the
  3165.    other would have information pertaining to the FCIP Entity.
  3166.  
  3167.    The two documents focus on different objectives. As mentioned above,
  3168.    implementation of FCIP will lead to IP encapsulation within IP.
  3169.    While perhaps inefficient, this should not lead to issues with IP
  3170.    communication. One caveat: if a Fibre Channel device is
  3171.    encapsulating IP packets in an FC Frame (e.g. an IPFC device), and
  3172.    that device is communicating with a device running IP over a non-FC
  3173.    medium, a second IPFC device may need to act as a gateway between
  3174.    the two networks. This scenario is not specifically addressed by FCIP.
  3175.  
  3176.    There is nothing in either of the specifications to prevent a single
  3177.    device from implementing both FCIP and IP-over-FC (IPFC), but this
  3178.    is implementation specific, and is beyond the scope of this document.
  3179.  
  3180.  
  3181.  
  3182. APPENDIX F - FC Frame Format
  3183.  
  3184.    The contents of this annex are informative.
  3185.  
  3186.    All FC Frames have a standard format (see FC-FS [6]) much like LAN's
  3187.    802.x protocols. However, the exact size of each FC Frame varies
  3188.  
  3189.  
  3190. Rajagopal, et al.               Standards Track                [Page 58]
  3191.  
  3192. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3193.  
  3194.  
  3195.    depending on the size of the variable fields. The size of the
  3196.    variable field ranges from 0 to 2112-bytes as shown in the FC Frame
  3197.    Format in figure 16 resulting in the minimum size FC Frame of 36
  3198.    bytes and the maximum size FC Frame of 2148 bytes. Valid FC Frame
  3199.    lengths are always a multiple of four bytes.
  3200.  
  3201.        +------+--------+-----------+----//-------+------+------+
  3202.        | SOF  |Frame   |Optional   |  Frame      | CRC  |  EOF |
  3203.        | (4B) |Header  |Header     | Payload     | (4B) | (4B) |
  3204.        |      |(24B)   |<----------------------->|      |      |
  3205.        |      |        | Data Field = (0-2112B)  |      |      |
  3206.        +------+--------+-----------+----//-------+------+------+
  3207.  
  3208.        Fig. 16  FC Frame Format
  3209.  
  3210. SOF and EOF Delimiters
  3211.  
  3212.    On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are
  3213.    called Ordered Sets and are sent as special words constructed from
  3214.    the 8B/10B comma character (K28.5) followed by three additional 8B/
  3215.    10B data characters making them uniquely identifiable in the data
  3216.    stream.
  3217.  
  3218.    On an FC link the SOF delimiter serves to identify the beginning of
  3219.    an FC Frame and prepares the receiver for FC Frame reception. The
  3220.    SOF contains information about the FC Frame's Class of Service,
  3221.    position within a sequence, and in some cases, connection status.
  3222.  
  3223.    The EOF delimiter identifies the end of the FC Frame and the final
  3224.    FC Frame of a sequence. In addition, it serves to force the running
  3225.    disparity to negative. The EOF is used to end the connection in
  3226.    connection-oriented classes of service.
  3227.  
  3228.    A special EOF delimiter called EOFa (End Of Frame - Abort) is used
  3229.    to terminate a partial FC Frame resulting from a malfunction in a
  3230.    link facility during transmission. Since an FCIP Entity functions
  3231.    like a transmission link with respect to the rest of the FC Fabric,
  3232.    FCIP_DEs may use EOFa in their error recovery procedures.
  3233.  
  3234.    It is therefore important to preserve the information conveyed by
  3235.    the delimiters across the IP-based network, so that the receiving
  3236.    FCIP Entity can correctly reconstruct the FC Frame in its original
  3237.    SOF and EOF format before forwarding it to its ultimate FC
  3238.    destination on the FC link.
  3239.  
  3240.    When an FC Frame is encapsulated and sent over a byte-oriented
  3241.    interface, the SOF and EOF delimiters are represented as sequences
  3242.    of four consecutive bytes, which carry the equivalent Class of
  3243.  
  3244.  
  3245. Rajagopal, et al.               Standards Track                [Page 59]
  3246.  
  3247. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3248.  
  3249.  
  3250.    Service and FC Frame termination information as the FC ordered sets.
  3251.    The representation of SOF and EOF in an encapsulation FC Frame is
  3252.    described in FC Frame Encapsulation [20].
  3253.  
  3254. Frame Header
  3255.  
  3256.    The FC Frame Header is transparent to the FCIP Entity. The FC Frame
  3257.    Header is 24 bytes long and has several fields that are associated
  3258.    with the identification and control of the payload. Current FC
  3259.    Standards allow up to 3 Optional Header fields [6]:
  3260.  
  3261.     - Network_Header (16-bytes)
  3262.     - Association_Header (32-bytes)
  3263.     - Device_Header (up to 64-bytes).
  3264.  
  3265. Frame Payload
  3266.  
  3267.    The FC Frame Payload is transparent to the FCIP Entity. An FC
  3268.    application level payload is called an Information Unit at the FC-4
  3269.    Level. This is mapped into the FC Frame Payload of the FC Frame. A
  3270.    large Information Unit is segmented using a structure consisting of
  3271.    FC Sequences. Typically, a Sequence consists of more than one FC
  3272.    Frame. FCIP does not maintain any state information regarding the
  3273.    relationship of FC Frames within a FC Sequence.
  3274.  
  3275. CRC
  3276.  
  3277.    The FC CRC is 4 bytes long and uses the same 32-bit polynomial used 
  3278.    in FDDI and is specified in ANSI X3.139 Fiber Distributed Data
  3279.    Interface. This CRC value is calculated over the entire FC header
  3280.    and the FC payload; it does not include the SOF and EOF delimiters.
  3281.  
  3282.    Note: When FC Frames are encapsulated into FCIP Frames, the FC Frame
  3283.    CRC is untouched by the FCIP Entity.
  3284.  
  3285.  
  3286. APPENDIX G - FC Encapsulation Format
  3287.  
  3288.    This annex contains a reproduction of the FC Encapsulation Format
  3289.    [20] as it applies to FCIP Frames that encapsulate FC Frames. The
  3290.    information in this annex is not intended to represent the FCIP
  3291.    Special Frame (FSF) that is described in section 8.
  3292.  
  3293.    The information in this annex was correct as of the time this
  3294.    specification was approved. The information in this annex is
  3295.    informative only.
  3296.  
  3297.  
  3298.  
  3299.  
  3300. Rajagopal, et al.               Standards Track                [Page 60]
  3301.  
  3302. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3303.  
  3304.  
  3305.  
  3306.    If there are any differences between the information here and the FC
  3307.    Encapsulation Format specification [20], the FC Encapsulation Format
  3308.    specification takes precedence.
  3309.  
  3310.    If there are any differences between the information here and the
  3311.    contents of section 6.6.1, then the contents of section 6.6.1 take
  3312.    precedence.
  3313.  
  3314.    Figure 17 applies the requirements stated in section 6.6.1 and in
  3315.    the FC Encapsulation Frame format resulting in a summary of the FC
  3316.    Frame format. Where FCIP requires specific values, those values are
  3317.    shown in hexadecimal in parentheses. Detailed requirements for the
  3318.    FCIP usage of the FC Encapsulation Format are in section 6.6.1.
  3319.  
  3320.    W|------------------------------Bit------------------------------|
  3321.    o|                                                               |
  3322.    r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
  3323.    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|
  3324.     +---------------+---------------+---------------+---------------+
  3325.    0|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
  3326.     |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
  3327.     +---------------+---------------+---------------+---------------+
  3328.    1|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
  3329.     |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
  3330.     +---------------+---------------+---------------+---------------+
  3331.    2|    pFlags     |    Reserved   |    -pFlags    |  -Reserved    |
  3332.     |     (0x00)    |     (0x00)    |     (0xFF)    |    (0xFF)     |
  3333.     +-----------+---+---------------+-----------+---+---------------+
  3334.    3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
  3335.     |   (0x00)  |                   |   (0x3F)  |                   |
  3336.     +-----------+-------------------+-----------+-------------------+
  3337.    4|                      Time Stamp [integer]                     |
  3338.     +---------------------------------------------------------------+
  3339.    5|                      Time Stamp [fraction]                    |
  3340.     +---------------------------------------------------------------+
  3341.    6|                     CRC (Reserved in FCIP)                    |
  3342.     |                        (0x00-00-00-00)                        |
  3343.     +---------------+---------------+---------------+---------------+
  3344.    7|      SOF      |      SOF      |     -SOF      |     -SOF      |
  3345.     +---------------+---------------+---------------+---------------+
  3346.    8|                                                               |
  3347.     +-----            FC Frame content (see appendix F)        -----+
  3348.     |                                                               |
  3349.     +---------------+---------------+---------------+---------------+
  3350.    n|      EOF      |      EOF      |     -EOF      |     -EOF      |
  3351.     +---------------+---------------+---------------+---------------+
  3352.  
  3353.  
  3354.  
  3355. Rajagopal, et al.               Standards Track                [Page 61]
  3356.  
  3357. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3358.  
  3359.  
  3360.        Fig. 17  FCIP Frame Format
  3361.  
  3362.    The names of fields are generally descriptive on their contents and
  3363.    the FC Encapsulation Format specification [20] is referenced for
  3364.    details. Field names preceded by a minus sign are ones complement
  3365.    values of the named field.
  3366.  
  3367.    Note: Figure 17 does not represent the FSF that is described in
  3368.    section 8.
  3369.  
  3370.  
  3371. APPENDIX H - FCIP Requirements on an FC Entity
  3372.  
  3373.    The contents of this annex are informative for FCIP but might be
  3374.    considered normative on FC-BB-2.
  3375.  
  3376.    The capabilities that FCIP requires of an FC Entity include:
  3377.  
  3378.    1)  The FC Entity must deliver FC Frames to the correct FCIP Data
  3379.        Engine (in the correct FCIP Link Endpoint).
  3380.  
  3381.    2)  Each FC Frame delivered to an FCIP_DE must be accompanied by a
  3382.        time value synchronized with the clock maintained by the FC
  3383.        Entity at the other end of the FCIP Link (see section 7). If a
  3384.        synchronized time value is not available, a value of zero must
  3385.        accompany the FC Frame.
  3386.  
  3387.    3)  When FC Frames exit FCIP Data Engine(s) via the FC Frame
  3388.        Transmitter Portal(s), the FC Entity should forward them to the
  3389.        FC Fabric. However, before forwarding a FC Frame the FC Entity
  3390.        must compute the end-to-end transit time for the FC Frame using
  3391.        the time value supplied by the FCIP_DE (taken from the FCIP
  3392.        header) and a synchronized time value (see section 7). If the
  3393.        end-to-end transit time exceeds the requirements of the FC
  3394.        Fabric, the FC Entity is responsible for discarding the FC Frame.
  3395.  
  3396.    4)  The only delivery ordering guarantee provided by FCIP is
  3397.        correctly ordered delivery of FC Frames between a pair of FCIP
  3398.        Data Engines. FCIP expects the FC Entity to implement all other
  3399.        FC Frame delivery ordering requirements.
  3400.  
  3401.    5)  When a TCP connect request is received and that request would
  3402.        add a new TCP Connection to an existing FCIP_LEP, the FC Entity
  3403.        must authenticate the source of the TCP connect request before
  3404.        use of the new TCP connection is allowed.
  3405.  
  3406.    6)  The FC Entity may participate in determining allowed TCP
  3407.        Connections, TCP Connection parameters, quality of service
  3408.  
  3409.  
  3410. Rajagopal, et al.               Standards Track                [Page 62]
  3411.  
  3412. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3413.  
  3414.  
  3415.        usage, and security usage by modifying interactions with the
  3416.        FCIP Entity that are modelled as a "shared" database in section
  3417.        9.1.1.
  3418.  
  3419.    7)  The FC Entity may require the FCIP Entity to perform TCP close
  3420.        requests.
  3421.  
  3422.    8)  The FC Entity may recover from connection failures.
  3423.  
  3424.    9)  The FC Entity must recover from events that the FCIP Entity
  3425.        cannot handle, such as:
  3426.        a)  loss of synchronization with FCIP Frame headers from the
  3427.            Encapsulated Frame Receiver Portal requiring resetting the
  3428.            TCP Connection; and
  3429.        b)  recovering from FCIP Frames that are discarded as a result
  3430.            of synchronization problems (see section 6.6.2.2 and section
  3431.            6.6.2.3).
  3432.  
  3433.    10) The FC Entity must work cooperatively with the FCIP Entity to
  3434.        manage flow control problems in either the IP Network or FC
  3435.        Fabric.
  3436.  
  3437.    11) The FC Entity may test for failed TCP Connections.
  3438.  
  3439.    Note that the Fibre Channel standards must be consulted for a
  3440.    complete understanding of the requirements placed on an FC Entity.
  3441.  
  3442.    Table 2 shows the explicit interactions between the FCIP Entity and
  3443.    the FC Entity.
  3444.  
  3445.    +-------------+-----------------+-----------------------------------+
  3446.    |             |                 | Information/Parameter Passed and  |
  3447.    |             |                 |             Direction             |
  3448.    | Reference   |                 +-----------------+-----------------+
  3449.    |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
  3450.    +-------------+-----------------+-----------------+-----------------+
  3451.    | 6.6         | FC Frame ready  |                 | Provide FC      |
  3452.    | FCIP Data   | for IP transfer |                 | Frame and       |
  3453.    | Engine      |                 |                 | time stamp at   |
  3454.    |             |                 |                 | FC Frame        |
  3455.    |             |                 |                 | Receiver Portal |
  3456.    +-------------+-----------------+-----------------+-----------------+
  3457.    | WWN = World Wide Name                                             |
  3458.    +-------------------------------------------------------------------+
  3459.    |                           continued                               |
  3460.    +-------------------------------------------------------------------+
  3461.  
  3462.        Table 2  FC/FCIP Entity pair interactions (part 1 of 5)
  3463.  
  3464.  
  3465. Rajagopal, et al.               Standards Track                [Page 63]
  3466.  
  3467. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3468.  
  3469.  
  3470.    +-------------+-----------------+-----------------------------------+
  3471.    |             |                 | Information/Parameter Passed and  |
  3472.    |             |                 |             Direction             |
  3473.    | Reference   |                 +-----------------+-----------------+
  3474.    |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
  3475.    +-------------+-----------------+-----------------+-----------------+
  3476.    |                           continued                               |
  3477.    +-------------+-----------------+-----------------+-----------------+
  3478.    | 6.6         | FCIP Frame      | Provide FC      |                 |
  3479.    | FCIP Data   | received from   | Frame and       |                 |
  3480.    | Engine      | IP Network      | time stamp at   |                 |
  3481.    |             |                 | FC Frame Trans- |                 |
  3482.    |             |                 | mitter Portal   |                 |
  3483.    +-------------+-----------------+-----------------+-----------------+
  3484.    | 6.6.2.2     | FCIP_DE         | Inform FC       |                 |
  3485.    | Errors      | discards bytes  | Entity that     |                 |
  3486.    | in FCIP     | delivered       | bytes have been |                 |
  3487.    | Headers and | through         | discarded with  |                 |
  3488.    | Discarding  | Encapsulated    | reason          |                 |
  3489.    | FCIP Frames | Frame Receiver  |                 |                 |
  3490.    |             | Portal          |                 |                 |
  3491.    +-------------+-----------------+-----------------+-----------------+
  3492.    | 6.6.2.3     | FCIP Entity     | Inform FC       |                 |
  3493.    | Synchron-   | closes TCP      | Entity that TCP |                 |
  3494.    | ization     | Connection due  | Connection has  |                 |
  3495.    | Failures    | to synchron-    | been closed     |                 |
  3496.    |             | ization failure | with reason     |                 |
  3497.    |             |                 | for closure     |                 |
  3498.    +-------------+-----------------+-----------------+-----------------+
  3499.    | 9.1.2.3     | Receipt of the  | Inform FC       |                 |
  3500.    | Connection  | echoed FSF      | Entity that TCP |                 |
  3501.    | Setup       | takes too long  | Connection has  |                 |
  3502.    | Following a | or the FSF      | been closed     |                 |
  3503.    | Successful  | contents have   | with reason     |                 |
  3504.    | TCP Connect | changed         | for closure     |                 |
  3505.    | Request     |                 |                 |                 |
  3506.    +-------------+-----------------+-----------------+-----------------+
  3507.    | WWN = World Wide Name                                             |
  3508.    +-------------------------------------------------------------------+
  3509.    |                           continued                               |
  3510.    +-------------------------------------------------------------------+
  3511.  
  3512.        Table 2 FC/FCIP Entity pair interactions (part 2 of 5)
  3513.  
  3514.  
  3515.  
  3516.  
  3517.  
  3518.  
  3519.  
  3520. Rajagopal, et al.               Standards Track                [Page 64]
  3521.  
  3522. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3523.  
  3524.  
  3525.    +-------------+-----------------+-----------------------------------+
  3526.    |             |                 | Information/Parameter Passed and  |
  3527.    |             |                 |             Direction             |
  3528.    | Reference   |                 +-----------------+-----------------+
  3529.    |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
  3530.    +-------------+-----------------+-----------------+-----------------+
  3531.    |                           continued                               |
  3532.    +-------------+-----------------+-----------------+-----------------+
  3533.    | 9.1.2.1     | New TCP         | Inform FC       |                 |
  3534.    | Non-Dynamic | Connection      | Entity of       |                 |
  3535.    | Creation of | created based   | new or existing |                 |
  3536.    | a New TCP   | on "shared"     | FCIP_LEP and    |                 |
  3537.    | Connections | database        | new FCIP_DE     |                 |
  3538.    |             | information     | along with      |                 |
  3539.    |             |                 | Destination FC  |                 |
  3540.    |             |                 | Fabric Entity   |                 |
  3541.    |             |                 | WWN, Connection |                 |
  3542.    |             |                 | Usage Flags,    |                 |
  3543.    |             |                 | Connection      |                 |
  3544.    |             |                 | Usage Code and  |                 |
  3545.    |             |                 | Connection      |                 |
  3546.    |             |                 | Nonce           |                 |
  3547.    +-------------+-----------------+-----------------+-----------------+
  3548.    | 9.1.2.2     | New TCP         | Inform FC       |                 |
  3549.    | Dynamic     | Connection      | Entity of       |                 |
  3550.    | Creation of | created based   | new or existing |                 |
  3551.    | a New TCP   | on SLP service  | FCIP_LEP and    |                 |
  3552.    | Connections | advertisement   | new FCIP_DE     |                 |
  3553.    |             | and "shared"    | along with      |                 |
  3554.    |             | database        | Destination FC  |                 |
  3555.    |             | information     | Fabric Entity   |                 |
  3556.    |             |                 | WWN, Connection |                 |
  3557.    |             |                 | Usage Flags,    |                 |
  3558.    |             |                 | Connection      |                 |
  3559.    |             |                 | Usage Code and  |                 |
  3560.    |             |                 | Connection      |                 |
  3561.    |             |                 | Nonce           |                 |
  3562.    +-------------+-----------------+-----------------+-----------------+
  3563.    | WWN = World Wide Name                                             |
  3564.    +-------------------------------------------------------------------+
  3565.    |                           continued                               |
  3566.    +-------------------------------------------------------------------+
  3567.  
  3568.        Table 2 FC/FCIP Entity pair interactions (part 3 of 5)
  3569.  
  3570.  
  3571.  
  3572.  
  3573.  
  3574.  
  3575. Rajagopal, et al.               Standards Track                [Page 65]
  3576.  
  3577. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3578.  
  3579.  
  3580.    +-------------+-----------------+-----------------------------------+
  3581.    |             |                 | Information/Parameter Passed and  |
  3582.    |             |                 |             Direction             |
  3583.    | Reference   |                 +-----------------+-----------------+
  3584.    |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
  3585.    +-------------+-----------------+-----------------+-----------------+
  3586.    |                           continued                               |
  3587.    +-------------+-----------------+-----------------+-----------------+
  3588.    | 9.1.3       | New TCP         | Inform FC       |                 |
  3589.    | Processing  | Connection      | Entity of       |                 |
  3590.    | Incoming    | created based   | new or existing |                 |
  3591.    | TCP Connect | on incoming TCP | FCIP_LEP and    |                 |
  3592.    | Requests    | Connect request | new FCIP_DE     |                 |
  3593.    |             | and "shared"    | along with      |                 |
  3594.    |             | database        | Source FC       |                 |
  3595.    |             | information     | Fabric Entity   |                 |
  3596.    |             |                 | WWN, Source     |                 |
  3597.    |             |                 | FC/FCIP Entity  |                 |
  3598.    |             |                 | Identifier,     |                 |
  3599.    |             |                 | Connection      |                 |
  3600.    |             |                 | Usage Flags,    |                 |
  3601.    |             |                 | Connection      |                 |
  3602.    |             |                 | Usage Code and  |                 |
  3603.    |             |                 | Connection      |                 |
  3604.    |             |                 | Nonce           |                 |
  3605.    +-------------+-----------------+-----------------+-----------------+
  3606.    | 9.1.3       | TCP Connect     | Request FC      | Yes or No       |
  3607.    | Processing  | Request wants   | Entity to       | answer about    |
  3608.    | Incoming    | to add a new    | authenticate    | whether the     |
  3609.    | TCP Connect | TCP Connection  | the source of   | source of the   |
  3610.    | Requests    | to an existing  | the TCP Connect | TCP Connect     |
  3611.    |             | FCIP_LEP        | Request         | Request can be  |
  3612.    |             |                 |                 | authenticated   |
  3613.    +-------------+-----------------+-----------------+-----------------+
  3614.    | 9.1.3       | Receipt of the  | Inform FC       |                 |
  3615.    | Processing  | FSF takes too   | Entity that TCP |                 |
  3616.    | Incoming    | long or         | Connection has  |                 |
  3617.    | TCP Connect | duplicate       | been closed     |                 |
  3618.    | Requests    | Connection      | with reason     |                 |
  3619.    |             | Nonce value     | for closure     |                 |
  3620.    +-------------+-----------------+-----------------+-----------------+
  3621.    | WWN = World Wide Name                                             |
  3622.    +-------------------------------------------------------------------+
  3623.    |                           continued                               |
  3624.    +-------------------------------------------------------------------+
  3625.  
  3626.        Table 2 FC/FCIP Entity pair interactions (part 4 of 5)
  3627.  
  3628.  
  3629.  
  3630. Rajagopal, et al.               Standards Track                [Page 66]
  3631.  
  3632. Internet-Draft        Fibre Channel Over TCP/IP (FCIP)         May, 2002
  3633.  
  3634.  
  3635.    +-------------+-----------------+-----------------------------------+
  3636.    |             |                 | Information/Parameter Passed and  |
  3637.    |             |                 |             Direction             |
  3638.    | Reference   |                 +-----------------+-----------------+
  3639.    |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
  3640.    +-------------+-----------------+-----------------+-----------------+
  3641.    |                           concluded                               |
  3642.    +-------------+-----------------+-----------------+-----------------+
  3643.    | 9.2         | FC Entity       | Acknowledgement | Identification  |
  3644.    | Closing TCP | determines      | of TCP          | of the FCIP_DE  |
  3645.    | Connections | that a TCP      | Connection      | whose TCP       |
  3646.    |             | Connection      | closure         | Connection      |
  3647.    |             | needs to be     |                 | needs to be     |
  3648.    |             | closed          |                 | closed          |
  3649.    +-------------+-----------------+-----------------+-----------------+
  3650.    | 9.4         | Discovery that  | Inform FC       |                 |
  3651.    | TCP         | TCP connectiv-  | Entity that TCP |                 |
  3652.    | Connection  | ity has been    | Connection has  |                 |
  3653.    | Considera-  | lost            | been closed     |                 |
  3654.    | tions       |                 | with reason     |                 |
  3655.    |             |                 | for closure     |                 |
  3656.    +-------------+-----------------+-----------------+-----------------+
  3657.    | 10.4.3      | Excessive       | Inform FC       |                 |
  3658.    | Handling    | numbers of      | Entity that TCP |                 |
  3659.    | data        | dropped         | Connection has  |                 |
  3660.    | integrity   | datagrams       | been closed     |                 |
  3661.    | and confi-  | detected and    | with reason     |                 |
  3662.    | dentiality  | TCP Connection  | for closure     |                 |
  3663.    | violations  | closed          |                 |                 |
  3664.    +-------------+-----------------+-----------------+-----------------+
  3665.    | ips Secur-  | TCP Connection  | Inform FC       |                 |
  3666.    | ity draft   | closed due to   | Entity that TCP |                 |
  3667.    |             | SA parameter    | Connection has  |                 |
  3668.    | Handling SA | mismatch        | been closed     |                 |
  3669.    | parameter   | problems        | with reason     |                 |
  3670.    | mismatches  |                 | for closure     |                 |
  3671.    +-------------+-----------------+-----------------+-----------------+
  3672.    | WWN = World Wide Name                                             |
  3673.    +-------------------------------------------------------------------+
  3674.  
  3675.        Table 2 FC/FCIP Entity pair interactions (part 5 of 5)
  3676.  
  3677.  
  3678.  
  3679.  
  3680.  
  3681.  
  3682.  
  3683.  
  3684.  
  3685. Rajagopal, et al.               Standards Track                [Page 67]
  3686.