NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Elizabeth Rodriguez <firstname.lastname@example.org>
David Black <email@example.com>
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe ips
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 will address at least the following:
- Congestion control suitable for shared traffic network environments such as the Internet.
- Security measures, including authentication and privacy, sufficient to defend against threats up to and including those that can be expected on a public network.
- 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).
The WG will address security and congestion control as an integral part of bits protocol encapsulation(s); naming, discovery, and management are important related issues, but may be addressed in companion documents.
The WG specifications will provide support for 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 utilizing 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 a framework document that provides an overview of the environments in which its encapsulated protocols and related protocols are expected to operate. 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.
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 hold primary responsibility 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 (firstname.lastname@example.org)
Fibre Channel (FC-2) over IP: Murali Rajagopal (email@example.com)
Submit the initial protocol encapsulations as working group Internet-Drafts.
Submit initial version of framework document as an Internet-Draft.
Discuss drafts and issues at the IETF meeting in San Diego.
Submit final versions of requirements drafts to the IESG for consideration as Informational RFCs.
Discuss framework, specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations at IETF meeting in Minneapolis.
Submit protocol specification drafts to the IESG for consideration as Proposed Standard RFCs.
Begin revision of WG charter in consultation with the Area Directors.
Meet at IETF meeting to close any open issues and finish any outstanding work items, including MIB, discovery, and framework drafts.
Submit MIB, discovery, framework, and any other WG drafts to the IESG for consideration as appropriate to each draft.
IPS WG Meeting Minutes IETF #50
Interim Meeting - There will be an interim meeting for the IPS working group.
It will be co-located with T10 in Nashua, NH on April 30 & May 1.
FC related topics will be covered on Monday, April 30.
SCSI related documents will be covered on Tuesday, May 1.
In addition to the IPS meetings, on Wednesday, May 2, during the T10 CAP meeting, a discussion of a SCSI MIB will be held.
Details of this meeting, including location and hotel room information, have been sent to the IPS mailing list.
TCP framing discussion will be in TSVWG WG meeting the evening of Monday, March 19.
IPS working group attendees are encouraged to attend, be familiar with the draft, and ask questions. The draft was cross-posted to both IPS and TSVWG mailing lists.
To subscribe to the TSVWG mailing list or to view the archive, see www.ietf.org/mailman/listinfo/tsvwg
RDMA - RDMA is a separate effort from the framing discussion.
A separate mailing list has been formed to address RDMA
To join, send an email to firstname.lastname@example.org .
***NOTE***: This address has been corrected from the one discussed in the meeting.
T10 is considering a new SCSI model. T10 participants agreed that it may have advantages but will be very different from current SCSI model. Therefore it is currently deferred to SAM-3.
This model may be of interested to iSCSI, as it will have advantages for iSCSI.
-- iSCSI Requirements --
iSCSI requirements - document is almost complete.
1 more draft will be sent out, and then a last call will occur in approximately 1 month with the hope of submitted the result as an informational RFC around the time of the interim meeting (end of April). Everyone should review the draft on the list and especially check that the MUSTs and SHOULDs are correct and nothing is missing.
-- iSCSI specification - draft-ietf-ips-iscsi-05.txt --
- CRCs for iSCSI. Two presentations made with respect to CRC vs checksum usage in iSCSI.
Recommendation was to use a 32 bit CRC; three mentioned as candidates - CRC-32C; CRC-32Q and CCITT-CRC32. Reported that there really is no need for a 64 bit CRC.
Consensus call on use of CRC instead of checksum. Loud CRC hum; no hum for checksum, so use of CRC rather than checksums is the rough consensus of this meeting.
Consensus call will be taken on which CRC to use at interim meeting, so that WG has more time to investigate and understand the options presented.
Request made for a single mandatory to implement CRC algorithm as opposed to making the CRC algorithm selection negotiable.
- iSCSI Digests. Current draft has multiple digests.
3 proposals presented for digest and related header formats.
Request made for use of TLV format in whatever solution is finalized on.
Consensus call made to have 1 header digest instead of multiple.
Barry Reinhold and Julian Satran were asked to work and come back with a single proposed format at the Wed meeting. The rough consensus of the meeting was that the data length should always be in the same place in the header.
Consensus call - descriptors and diagrams should always be kept together in the document.
This is the rough consensus of the meeting.
Error Recovery will be addressed at the interim meeting
Public Key and TLS were removed in version 05 of the iSCSI draft.
Public Key will be reinstated in the 06 draft.
MUST provide authentication and data integrity.
MAY provide data privacy (encryption).
Need to have at least 1 mandatory to implement security protocol.
IPSec seems to be the selection in current draft.
Consensus call - Make IPSec mandatory to implement? Arguments against, no consensus.
Consensus call - mandatory to implement SRP? Hum against. Will be taken to interim meeting.
Both Public Key and Radius authentication mechanisms will be added to the next version of the draft.
- SCSI ACA discussion
ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that stops execution of a sequence of dependent SCSI commands when one of them fails. The situation surrounding it is complex - T10 specifies ACA in SAM2, and hence iSCSI has to specify it and endeavor to make sure that ACA gets implemented sufficiently (two independent interoperable implementations) to avoid dropping ACA in the transition from Proposed Standard to Draft Standard. On the list David Black noted that this would make ACA implementation at least a "SHOULD" rather than a "MAY".
The current iSCSI draft has language requiring use of ACA rather than implementation; that's overspecified (it's ok for cooperating iSCSI nodes to decide not to use ACA), and will be changed.
In practice, ACA is not a complete solution (e.g., if a Fibre Channel switch drops a frame due to a CRC error, ACA will not kick in). T10 has been working on other mechanisms that address problems that ACA addresses in a more comprehensive fashion, but has not moved to drop ACA from SAM2, hence iSCSI has to deal with it.
-- iSCSI Boot presentation - draft-ietf-ips-iscsi-boot-02.txt
This draft is relatively stable - the bulk of this draft will become an informational RFC rather than standards track. David Black will figure out whether some piece of it needs to be standards track.
-- iSCSI MIB work presented. - draft-bakke-iscsimib-02.txt
Difficulty in making this an iSCSI MIB only, in that there is no SCSI MIB currently, but people want to see both iSCSI and SCSI information addressed.
SCSI MIB will be a topic on the agenda at the next T10 CAP meeting, May 2.
iSCSI MIB accepted as a WG item; next submission will be official WG item.
-- iSCSI naming and Discovery presented -
Two discovery methods presented - iSNS and SLP based.
iSNS is an new name server, specific to IPS. Question raised as to why not use SLP. Separate SLP presentation presented following; both iSNS and SLP can be used. SLP works for basic discovery whereas iSNS provides additional information/capabilities, including management functionality.
-- URN Namespace document presented - draft-bakke-iscsi-wwui-urn-00.txt
While the meeting consensus was to accept this as an official WG work item, this was overridden by direction from the IESG subsequent to the meeting.
-- SLP document presented - draft-bakke-iscsi-slp-00.txt
Meeting consensus was to accept this as an official WG item.
-- Back to iSCSI headers (first thing Wednesday)
Follow up from Monday: Two header formats presented to WG for consideration. One has data length in fixed location, but limits size of data. Second more flexible, but data length field not in fixed location.
More details on each format to be written up and posted to list; decision on which header format to follow to be decided on list; Julian requests decision within 10 days. The list subsequently chose the "Format 2" prepared/proposed by Barry Reinhold.
-- iSNS draft presented - draft-ietf-ips-isns-01.txt
Primarily a status report and description of how iSNS applies to all three protocols in the WG (iFCP, iSCSI, FCIP). It's required by iFCP, but optional for the others.
Rationale for why SLP isn't enough and iSNS is needed will be sent to list.
A concern was raised about relying on iSNS for certificate distribution vs. certificate exchange between the two ends of an IP Storage connection. Not resolved in the meeting and will need further consideration as part of protocol security work.
-- Fibre Channel related topics: --
Fibre Channel Common Encapsulation team being formed.
Small team, with a target size of 6 people.
Interested people to see David or Elizabeth (co-chairs) by Friday, March 23.
Three encapsulation presentations made:
Two had encapsulation format recommendations -
draft-weber-fcip-encaps-00.txt and a presentation from Vi Chau (FCIP draft co-author)
Third consisted of requirements needed for iFCP -
Discussions of expectations from common encapsulation format - should provide some means of data integrity & synchronization by guarding against accidental interpretation of encapsulated data as an FC frame if framing synchronization to the data stream is lost and being recovered; this is not a requirement to provide a means of preventing intentional hijacking; simply a means of validation that what is seen is actually current and valid. The WG co-chair made it clear that the encapsulation design team must take this issue seriously.
FC Frames have CRC around them, so no CRC needed there, but what needs to be wrapped around the common encapsulation piece (header and/or header + SOF/EOF codes) to insure that data is correct?
Statement of direction from WG, based on show of hands, is that CRC should be used. This is the rough consensus of the meeting.
One requirement of the draft was initially to make the common header extensible - not needed by FCIP or iFCP. Consensus call - remove this requirement. This is the rough consensus of this meeting.
-- FCIP draft update discussed - draft-ietf-ips-fcovertcpip-01.txt
No draft submitted since Dec IETF meeting. Changes made and discussed by authors, but major pending changes did not make updated the draft for this meeting reasonable. Next draft will include changes recommended at both IETF-49 and the interim meeting, as well as a better description of the FCIP port models, encapsulation, etc.
Next draft due April, prior to next interim meeting.
-- FCIP Model presentation - Mike O'Donnell
FCIP port model usage. In current FCIP draft, unclear as to whether this is following a B-Port, E-Port or some other kind of port model. Presentation makes clear that both E-Ports and B-Ports can be used by the FCIP device. In the absence of FCIP, an inter-switch link in Fibre Channel connects two E-ports. If FCIP is implemented in the Fibre Channel switch, the result is a logical E-port communicating over FCIP.
If FCIP is implemented in an external bridge, a real E-port on the switch communicates with a B-port on the bridge and the result is still a logical E-port on the FCIP side of the switch. These implementation structures will interoperate (i.e., a logical E-port in a switch can communicate via FCIP with a logical E-port implemented in a bridge that uses a B-port to talk to an E-port on a switch - the FCIP protocol is the same).
FC-BB2 meeting announced - during T11 week in Toronto, Canada on April 9.
Meeting is open to all. FC-BB2 handles the aspects of FCIP usage that require Fibre Channel standards.
-- iFCP status - draft-ietf-ips-ifcp-00.txt
3 additional versions of the draft anticipated between now and August 2001.
Target is that this August draft will be complete, w/o any TBDs.
Noting that the draft contained a MIB lead to a more general discussion of MIBs.
In general, MIBs should be advanced as separate documents, and authors need to look at the FC MIBs developed in the ipfc WG to avoid duplication.
The iSCSI MIB may provide a model for some of the iFCP MIB.
Final note - somehow, we managed to get 3 anagrammed acronyms. FCIP and iFCP are protocols in this WG, and IPFC is the IP over Fibre Channel protocol done by the ipfc WG.
iSCSI -- a SCSI over TCP mapping
iSCSI Security Issues
iSCSI Digests CRC or Checksum?
AHLS in TLV format
iSCSI Boot: Stages
iSCSI MIB Team Status
iSCSI Naming & Discovery
A URN Name Space for iSCSI World-Wide Unique Identifiers
iSCSI -- a SCSI over TCP mapping
iSCSI PDU Header and Misc. Notes
Internet Storage Name Service
Using SLP to Discover iSCSI Targets and Name Services
FC Encapsulation for IETF ips WG
iFCP Encapsulation Requirements and Guidelines
FCIP and FC-BB-2 Port Usage Model
iFCP Specification Milestones