2.8.8 IP Storage (ips)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-28

Chair(s):

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  Review with ADs what (if any) additional work the WG should undertake.
Done  Submit NAA naming draft to IESG for publication as an RFC

Internet-Drafts:

  • draft-ietf-ips-iscsi-boot-12.txt
  • draft-ietf-ips-isns-22.txt
  • draft-ietf-ips-ifcp-14.txt
  • draft-ietf-ips-iscsi-slp-09.txt
  • draft-ietf-ips-iscsi-mib-09.txt
  • draft-ietf-ips-fcip-mib-06.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-05.txt
  • draft-ietf-ips-iwarp-da-00.txt
  • draft-ietf-ips-iser-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3347 I Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
    RFC3643 Standard FC Frame Encapsulation
    RFC3720 Standard iSCSI
    RFC3721 I iSCSI Naming and Discovery
    RFC3722 Standard String Profile for iSCSI Names
    RFC3723 Standard Securing Block Storage Protocols over IP
    RFC3783 I SCSI Command Ordering Considerations with iSCSI
    RFC3821 Standard Fibre Channel Over TCP/IP (FCIP)
    RFC3822 Standard Finding FCIP Entities Using SLPv2

    Current Meeting Report
    IP Storage (ips) WG - Washington DC minutes
    -------------------------------------------

    The IP Storage (ips) WG met 1300-1500 on Monday,
    November 8, 2004 at the IETF meetings in Washington, DC.

    AGENDA and MINUTES
    ------------------

    Letters in square brackets (e.g., [A]) indicate first character in
    filename of presentation.

    Administrivia, agenda bashing, draft status review, etc.: [A] 15 min David Black, EMC (co-chair)
    Blue sheets
    Note Well
    Milestones - iSER and DA to ADs in April/May 2005
    Draft status - All protocol drafts are in RFC Editor queue - iSNS DHC option will be there shortly after meeting - FCIP SLP template needs an errata to correct version # in template from 0.1 to 1.0 - Waiting on new versions of iSCSI MIB, iSCSI Auth MIB and FCIP MIB from draft authors. - iFCP and iSNS MIBs need author attention

    Any open MIB issues: [no slides] 15 min Elizabeth Rodriguez, Dot Hill (co-chair)
    FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt)
    - New field to be added to deal with a MIB instance that covers multiple switches. This was submitted as an IETF Last Call comment, but got lost. -06 version of MIB will be produced containing all agreed-to changes from -05 plus this change. Message will be sent to list to do a quick review of this final change.

    iSER and DA: [B] 1 hour Mike Ko, IBM
    (draft-ietf-ips-iser-00.txt)
    (draft-ietf-ips-iwarp-da-00.txt)
    iSER = iSCSI Extensions for RDMA
    DA = Datamover Architecture for iSCSI

    Control of unexpected PDUs
    - Sense of room: Using a key to limit # of outstanding unexpected PDUs is the right approach. "None" = "No Limit" is allowed. Minimum value (e.g., to avoid 1 or 2) is TBD [Open Issue]
    - Specified default value (None vs. specific value) in absence of negotiation will be taken to list. [Open Issue]
    - Draft will need to contain discussion of unexpected vs. expected PDUs and buffering requirements, and when an unexpected PDU ceases to be outstanding.
    - Add cautionary notes to avoid NOP-out and NOP-in abuse, but take this to the list, as there may be a possibility of being able to specify initiator behavior that always works. [Open Issue]
    - [Open Issue]'s to be discussed on list.

    iSER over InfiniBand: [C] 30 min John Hufferd, IBM
    No draft available. This time period is for discussion of possible work to support iSCSI over InfiniBand via iSER. The primary purpose of this time is a discussion of whether the IETF should undertake work in this area, and if so, what scope of work is appropriate (e.g., to avoid all of us having to become InfiniBand experts).

    Proposal is iSER over InfiniBand to enable use of iSCSI

    Terminology: RDMAP should be for the RDDP WG protocol only, and not generalized as proposed in the slides.

    Resolution: No real conclusion. Enabling reuse of IETF technology like iSCSI/iSER in other environments is a "good thing" in principle. OTOH, our AD is concerned about InfiniBand protocols (e.g., RC) getting out onto the Internet and causing problems. Proponents should produce Internet-Draft addressing architecture, intended usage, Infiniband to IP/Internet proxy (in particular, protocol stack layer diagram) and proposed division of work between IETF and IBTA that avoids need for serious InfiniBand expertise in IETF (e.g., the work needed to cope with old implementations of InfiniBand appears to belong in IBTA, not IETF). Based on WG discussion of that draft, the WG co-chairs, and ADs can determine appropriate next steps.

    Slides

    Agenda
    iSER Draft Status
    iSER on InfiniBand (and SCTP)