May 2001 Minutes
IEEE Computer Society
Storage System Standards
Working Group
(P1244, P1563)

Minutes
Meeting held May 15-17, 2001
At the Offices of Legato, Inc., Palo Alto, California

Jack Cole, IEEE Sponsor
Curtis Anderson, SSSWG Chair; Alan Rollow, SSSWG Vice Chair

1244.1  Architecture/Data Model
        Geoff Peck (principal), Curtis Anderson, Joel Williams,
        Murali Sathyanarayana
1244.2  Session Security, Authentication, and Initialization Protocol
        Bruce Haddon (principal 2000-), Jan Klier (principal 1997-2000),
        Curtis Anderson, Joel Williams
1244.3  Media Management Protocol
        Murali Sathyanarayana (principal), Curtis Anderson, Joel Williams
1244.4  Drive Management Protocol
        Joel Williams
1244.5  Library Management Protocol
        Joel Williams
1244.6  Media Manager Interchange Protocol
        Joel Williams (principal), Curtis Anderson
1244.7  Media Manager Control Interface Protocol
        no current editor
1244.8  The C Language Procedural Interface
        Paul Lockwood
1244.9  MMS User Mount Commands
        Alan Rollow
1244.10 MMS Standard Administrative and Operational Commands
        Alan Rollow
1244.11 MOVER
        Joel Williams
New Features List
        Curtis Anderson

ATTENDANCE (4).

• Minutes from the March meeting were approved without change.
  

• 1244.6 "Data export/import" - Curtis needs to create a DTD for the XML
  

• 1244.8 "C Language API" - The group discussed Paul's latest changes. It was decided to incorporate changes to support the Futures List items the group has been working on into the first version of 1244.8. The Futures List items will probably be balloted at roughly the same time as 1244.8 is balloted and we wanted a coordinated set of features.
  

• 1244.9 & 1244.10 "User and Admin CLI" - The group discussed Alan's latest proposals on how to structure the CLI arguments.
  

• 1244.11 "Mover" - The group took some time to reexamine our requirements for the Mover to ensure that we were solving the smallest problem that needed to be solved and to see if new developments like the advent of the IETF's iSCSI protocol have impacted the Mover. Here is the original list of motivations that we developed for the Mover some time ago:

1. label processing

2. location transparency

3. semantic homogenization

4. application portability

5. logical volume support

6. byte stream support

7. service characteristics

8. software RAIT

The group noted that when you exclude the major government science labs and the storage management software vendors, points 5, 6, and 8 do not seem to be in demand by end customers. Point 3 is happening already as a result of market forces pushing drive vendors to be more compatible with each other. Point 2 can be addressed by FibreChannel to iSCSI bridges (at a high dollar cost), or by software daemons that do iSCSI target mode
passthru to locally attached drives. The group believes that iSCSI will happen and that Open-Source-licensed target mode software daemon(s) will be available soon. The group concluded that drives attached via either iSCSI or FibreChannel will appear to the app just like locally attached drives while drives accessed via NDMP will not. That leaves points 1, 4, and 7. The MMS itself is the thing that needs/wants points 1 and 7. The industry would benefit from point 4.

• The group discussed how the application, the DM, and the Mover can arrive at a mutually agreeable access technique to the drive. It was decided that including more structured information into the drive handle was the cleanest solution, so the group discussed how to standardize the format of the drive handles returned by the MMS to the application.
  

• The overall model that the group decided on was that the Mover would be structured as library code that the application would link to, the app would ask the Mover what transport methods the Mover was able to support, the app would pass that info to the MMS on each MOUNT MMP command, that info would be combined with info on supported transport methods that the DM had given to the MMS, the DM would prepare the drive for the selected transport method and would return a Drive Handle to the app, and finally, the app would pass that Drive Handle with its structured information describing the chosen transport method to the Mover.
  

• A new function should be defined in the Mover API that allows the app to request a list of the data transport methods that the Mover knows how to support. This function might be called "MMStransports()".
  

• A new clause called PREFERREDMODE needs to be added to the MOUNT
  command in the MMP protocol. The proposed EBNF would be:

mountcmd ::= .... <preferredclause>* ....
preferredclause ::= 'preferredmode' '[' <token>+ ']'

Note that zero or more such clauses can be used in a MOUNT command. The allowable tokens are mount modes much like those use in the MOUNTMODE and FIRSTMOUNT clauses, and will also be listed in the Token Registry. The clause tells the MMS core to pick one of the listed modes, any one will do, but that the tokens are listed in preferred order. The MMS core should use the first one, if possible, otherwise it should use the second one, if possible, etc, until the list is exhausted. If it is not possible mount the cartridge using any of the listed tokens, then the mount command should fail.

• Each DM should define a DMCAPABILITYGROUP that lists all the data
  transport methods that the DM can support, with one value being the
  default. This group would be sent up to the MMS core in the DMP CONFIG
  command along with all the other information the DM sends to the core.
  

• If a PREFERREDMODE clause is not present in an MMP MOUNT command,
  the core will use the default mode for the capability group that lists
  all the supported transport methods.
  

• Note that the DM may have to make a decision when a DMP ATTACH command
  comes down from the MMS core if the attach mode does not imply enough info
  about the transport method selected. For example, if the selected
  transport method is "ndmp" but there is more than one host that can
  access the drive and provide an NDMP transport method, the DM will have
  to pick one of those hosts. As a counter-example, if the transport method
  selected is "ndmp@host12", then the choice of hosts is explicit and the
  DM does not have to make a choice.
  

• Some transport methods require several pieces of information in order
  to establish a connection between the Mover associated with the app
  and the software associated with the drive. A standard format has
  been defined for the contents of a Device Handle returned by a DM
  allowing the inclusion of such structured data. The Drive Handle will
  be opaque and should passed as a whole into the MMSopen() Mover API
  function. MMSopen() will parse and operate on the handle transparently
  to the application. The EBNF for a Drive Handle will be:

devhandle ::= '"' <attr>+ '"'
attr ::= <name> '\n' <value> '\n'
name ::= taken from the token registry category for such
value ::= arbitrary string

• Example tokens that might be defined in the Token Registry:

Token Example Value
----- -------------
localpath /dev/rmt/tps3d4nrnsv
NDMPhost bitbucket.engr
NDMPuser tapeuser
NDMPpassword onetimepass

• Some notes were made on how this might be implemented in the currently existing implementations of the MMS. The PREFERREDMODE clause can be implemented by appending more stuff to the app's MATCH clause like so: "(OR (DM.CAP == 'token') ...)". The core will need additional code to pick out of the match engine results candidate attach modes in the same order as the tokens in the clause. Paul will also provide a routine in 1244.8 that will pull a Drive Handle apart into a data structure.
  

• No discussion was held on 1244 Futures for these topics:
  

Session Disconnect/Reconnect
Event Notification Model
Central Configuration Management
LM-Based Drive Selection
Automatic Interlibrary Transfer
Fine Grained Security
Migrate Control
Self Description

• Tape Standards (1563.1 & 1563.2 & 1563.3) - No discussion.
  

• Curtis has (after the meeting but before these minutes were sent out) resent copies of the final versions of the balloted standards, in editable form, for all the documents as well as the accumulated information on the Futures List items.
  

• Errors found in published 1244 standards:

1. The EBNF for the MMP "allocate" command contains duplicated square braces.

2. The EBNF for the MMP "show" command should not require a match clause or a volname clause, they should both be optional, and it should require a "report" clause.
   

• Related Standards Organizations - Curtis (and possibly some others from this group) will be attending the Storage Networking Industry Association (SNIA) Storage Media Library Working Group (SMLWG) meeting on June 27 (8:00am to 12:00noon) at SNIA's Technology Center in Colorado Springs, Colorado. The purpose will be to help the SMLWG incorporate changes into their management model that will allow management of Media Managers like the SSSWG MMS. See http://www.snia.org for more information.
  

• Next Meeting: ** NOTE CHANGE IN LOCATION **
  July 17-19, 2001, in the Boulder, Colorado, area.
  

• Future Meetings:
  September 18-20, 2001, on the East Coast somewhere.
  November - Looking for suggestions.
  

Important links:
http://www.SSSWG.org - Our working group's web site
http://www.StorageConference.org - NASA-IEEE Mass Storage Conference
To be held in College Park, MD from 5/16-5/20, 2002.
http://www.IEEE-SSSC.org - IEEE Storage Standards Steering Committee
http://www.SNIA.org - Storage Networking Industry Association

Active discussion continues on the above topics on the email reflector
"work@ssswg.org". Please subscribe if you are interested in hearing more
by sending email to "majordomo@ssswg.org" with a body of "subscribe work". 

SSSWG Home