2.8.7 IP Storage (ips)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-07

Elizabeth Rodriguez <Elizabeth.Rodriguez@DotHill.com>
David Black <black_david@emc.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Technical Advisor(s):
Keith McCloghrie <kzm@cisco.com>
Murali Rajagopal <muralir@cox.net>
Franco Travostino <travos@nortelnetworks.com>
John Hufferd <hufferd@us.ibm.com>
Mailing Lists:
General Discussion: ips@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/ips
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/ips/index.html
Description of Working Group:
There is significant interest in using IP-based networks to transport block storage traffic. This group will pursue the pragmatic approach of encapsulating existing protocols, such as SCSI and Fibre Channel, in an IP-based transport or transports. The group will focus on the transport or transports and related issues (e.g., security, naming, discovery, and configuration), as opposed to modifying existing protocols. Standards for the protocols to be encapsulated are controlled by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]). The WG cannot assume that any changes it desires will be made in these standards, and hence will pursue approaches that do not depend on such changes unless they are unavoidable. In that case the WG will create a document to be forwarded to the standards group responsible for the technology explaining the issue and requesting the desired changes be considered. The WG will endeavor to ensure high quality communications with these standards organizations. The WG will consider whether a layered architecture providing common transport, security, and/or other functionality for its encapsulations is the best technical approach.

The protocols to be encapsulated expect a reliable transport, in that failure to deliver data is considered to be a rare event for which time-consuming recovery at higher levels is acceptable. This has implications for both the choice of transport protocols and design of the encapsulation(s). The WG's encapsulations may require quality of service assurances (e.g., bounded latency) to operate successfully; the WG will consider what assurances are appropriate and how to provide them in shared traffic environments (e.g., the Internet) based on existing IETF QoS mechanisms such as Differentiated Services.

Use of IP-based transports raises issues that do not occur in the existing transports for the protocols to be encapsulated. The WG's protocol encapsulations will incorporate the following:

- Congestion control suitable for shared traffic network environments such as the Internet.

- Security including authentication, keyed cryptographic data integrity and confidentiality, sufficient to defend against threats up to and including those that can be expected on a public network. Implementation of basic security functionality will be required, although usage may be optional.

The WG will also address the following issues related to its protocol encapsulations:

- Naming and discovery mechanisms for the encapsulated protocols on IP-based networks, including both discovery of resources (e.g., storage) for access by the discovering entity, and discovery for management.

- Management, including appropriate MIB definition(s) for the encapsulations.

- By agreement with the IESG, the WG will additionally develop MIB definitions for the SCSI and Fiber Channel standards.

The WG specifications will allow the implementation of bridges and gateways that connect to existing implementations of the encapsulated protocols. The WG will preserve the approaches to discovery, multi-pathing, booting, and similar issues taken by the protocols it encapsulates to the extent feasible.

It may be necessary for traffic using the WG's encapsulations to pass through Network Address Translators (NATs) and/or firewalls in some circumstances; the WG will endeavor to design NAT- and firewall-friendly protocols that do not dynamically select target ports or require Application Level Gateways.

Effective implementations of some IP transports for the encapsulated protocols are likely to require hardware acceleration; the WG will consider issues concerning the effective implementation of its protocols in hardware.

The standard internet checksum is weaker than the checksums use by other implementations of the protocols to be encapsulated. The WG will consider what levels of data integrity assurance are required and how they should be achieved.

The WG will produce requirements and specification documents for each protocol encapsulation, and may produce applicability statements. The requirements and specification documents will consider both disk and tape devices, taking note of the variation in scale from single drives to large disk arrays and tape libraries, although the requirements and specifications need not encompass all such devices.

The WG will not work on:

- Extensions to existing protocols such as SCSI and Fibre Channel beyond those strictly necessary for the use of IP-based transports.

- Modifications to internet transport protocols or approaches requiring transport protocol options that are not widely supported, although the WG may recommend use of such options for block storage traffic.

- Support for environments in which significant data loss or data corruption is acceptable.

- File system protocols.

Operational Structure:

Keith McCloghrie (kzm@cisco.com) will serve as the MIB and Network Management advisor for the WG.

Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows:

A technical coordinator will be identified and selected for each protocol encapsulation adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that encapsulation, working with and motivating the document editors, and evangelizing the group's work within both the community and relevant external organizations such as T10 and T11.

In addition to the normal responsibilities of IETF working group chairs, the IPS chairs are responsible for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group.

Coordinators for initially important encapsulations:

SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com)

Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@cox.net)

iFCP: Franco Travostino (travos@nortelnetworks.com)

Goals and Milestones:
Done  Submit the initial protocol encapsulations as working group Internet-Drafts.
Done  Submit initial version of framework document as an Internet-Draft.
Done  Discuss drafts and issues at the IETF meeting in San Diego.
Done  Discuss framework, specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations at IETF meeting in Minneapolis.
Done  Submit final version of iSCSI requirements draft to the IESG for consideration as Informational RFC.
Done  Submit initial Internet-Draft of FCIP/iFCP common encapsulation format
Done  Begin revision of WG charter in consultation with the Area Directors.
Done  Meet at IETF meeting in London to discuss specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations
Done  WG Last Call on IPS security considerations document.
Done  WG Last Calls on iSCSI, iSCSI naming/discovery, and iSCSI MIB.
Done  WG Last Calls on all WG drafts intended to be published as RFCs, except NAA naming draft
Done  Submit remaining non-MIB protocol drafts intended to be published as RFCs to IESG, except NAA naming draft
Done  Revise iSCSI boot draft to address security issues and submit to IESG
Done  Determine whether to advance NAA naming draft for publication as an RFC in consultation with Technical Committee T10
Done  Submit draft on iSCSI ordering considerations for SCSI commands to IESG for consideration as Informational.
Feb 04  Submit all remaining MIB drafts to IESG.
Mar 04  Submit NAA naming draft to IESG for publication as an RFC
Mar 04  Review with ADs what (if any) additional work the WG should undertake.
  • - draft-ietf-ips-iscsi-boot-12.txt
  • - draft-ietf-ips-isns-22.txt
  • - draft-ietf-ips-ifcp-14.txt
  • - draft-ietf-ips-iscsi-slp-08.txt
  • - draft-ietf-ips-iscsi-mib-09.txt
  • - draft-ietf-ips-fcip-mib-05.txt
  • - draft-ietf-ips-isns-mib-06.txt
  • - draft-ietf-ips-ifcp-mib-05.txt
  • - draft-ietf-ips-scsi-mib-07.txt
  • - draft-ietf-ips-fcmgmt-mib-05.txt
  • - draft-ietf-ips-auth-mib-05.txt
  • - draft-ietf-ips-iscsi-name-ext-04.txt
  • Request For Comments:
    RFC3347 I Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
    RFC3643StandardFC Frame Encapsulation
    RFC3721 I iSCSI Naming and Discovery
    RFC3722StandardString Profile for iSCSI Names
    RFC3723StandardSecuring Block Storage Protocols over IP
    RFC3783 I SCSI Command Ordering Considerations with iSCSI
    RFC3821StandardFibre Channel Over TCP/IP (FCIP)
    RFC3822StandardFinding FCIP Entities Using SLPv2

    Current Meeting Report

    IPS WG Minutes - FINAL
    60th IETF Meeting, San Diego
    Monday, August 2, 2030-2200

    -- Administrivia - Elizabeth Rodriguez & David Black, WG co-chairs [A]

    iFCP RFC publication is waiting for iSNS
    iSCSI boot RFC publication is waiting for iSCSI SLP and iSNS

    iSCSI SLP issue is believed to be simple to resolve. UPDATE after meeting: Has been resolved, instructions for revised draft version have been sent to draft authors.
    WG chairs will be working on getting iSNS through IESG next.

    iSNS MIB needs MIB Doctor review plus nit check, and then will be forwarded to ADs/IESG, completing current charter.

    iSER/DA status - Normative dependence on MPA forces any standards track status for these drafts to be TBD. MPA status in RDDP WG to be resolved after RDDP WG Last Call

    Broadcom IPR notice on MPA should be updated to RFC 3668 by end of August.

    -- iSCSI and RDMA overview - Mallikarjun Chadalapaka, HP [B]

    DA is an architecture for realizing a datamover service underneath iSCSI. It has a well-defined functional interface.

    DA is not a wire protocol specification. Should be stable as iSCSI evolves forward to future versions. Should allow other RDMA services, not just RDDP.

    iSER is specific realization of Datamover Architecture over RDDP.

    - David Black (WG co-chair) would prefer iSER to be a standards-track candidate, and DA to be only informational. Diffserv is similar see RFC 2474 and RFC 2475; the informational RFC (2475) is more important as it contains the overall description of the architecture. DA contains no MUSTs that specify bits on the wire.
    - iSER requires RDMAP to run over TCP, as TCP to SCTP transition is not specified in iSER, hence current iSER draft requires MPA.

    -- iSER - Mike Ko, IBM Almaden

    MPA has made CRC optional, iSER needs to make sure that some lower layer has CRC32C or better. Will need to strengthen MPA text to take out this situation in which iSER has to restrict MPA.
    UPDATE after meeting: RDDP WG meeting decided that strengthening MPA text is the right approach.

    Draft will be changed to allow resource allocation before or after mode negotiation. If done before and mode negotiation fails then resources have to be released - put in language allowing functionally equivalent behavior. --> This is a **general** requirement on the draft.

    Notice_Key_Values - use lower case "may" as functional equivalence on wire is all that is required.

    RDMAExtensions overrides both Digest and Marker keys, even if negotiated to the wrong values. Respond with Irrelevant if RDMAExtensions=Yes and any of these keys were negotiated.

    RDMA Extensions Scope - currently session-wide scope (Leading Only). iSER not designed to support mixed mode connections. R2TSN won't work right in reassignment case. Anyone who wants mixed sessions needs to come back with a fully worked out proposal for how everything works at ErrorRecoveryLevel=2.

    Not every slide covered - take remaining issues to list.

    -- Request to WG: [D]

    - Accept both iSER and DA drafts as official WG work items.
    - iSER to be standards track vs. informational depending on status of MPA.
    - DA to be informational architecture document based on revisions to iSER to be functionally self-contained.

    The sense of the room in San Diego is to accept this request. WG chairs will work with ADs to make this happen.


    iSCSI/RDMA: Overview of DA and iSER
    iSCSI Extensions for RDMA (iSER)
    Proposal to IPS WG