CURRENT MEETING REPORT

Minutes of the MessageWay Working Group (msgway)

Reported by Danny Cohen, Myricom

The MessageWay Working Group met on Monday evening, led by Danny Cohen of Myricom. Danny gave a brief overview of MessageWay. The MessageWay End-to-End protocol (EEP) was specified in December 1995 (at the 34thIETF), the MessageWay Router-to Router protocol (RRP) is already specified now (at the 35th IETF), and the MessageWay Resource Discovery and Allocation Protocol (REDAP) is planned to be specified by June 1996 (at 36th IETF).

Interested parties may subscribe to the MessageWay mailing list, by sending an e-mail request to MsgWay-request@myri.com. To access the MessageWay archived documentation, use the URL ftp://ftp.isi.edu/msgway/msgway.mail.

Danny then introduced proposed changes to the MessageWay header which are practically as recommended by Tony Skjellum in an earlier email to the MsgWay Working Group.

Tony gave a presentation of the proposed MessageWay header changes. The changes are intended to extend the address range (from 16 bits to 24 bits), to enable optional hierarchical addressing, and to add EEP-header-optional-fields ("options") capability (for user implementation flexibility).

The extended address range is needed to overcome the current MessageWay 64K address limit. In large System Area Networks (SANs), such as Paragon, there may be up to 9K nodes, each with one or more physical and logical MessageWay addresses. A MessageWay interconnection of several such large SANs would exceed the MessageWay address space. Going to a 24-bit address increases the address limit to 8M. The proposed 24-bit address structure uses the first one-to-four bits to indicate the type of address. If the first bit is 0, then it is a physical address. Otherwise, the address type is that shown below, where "x" = "don't care":

BITS ADDRESS TYPE

11xx L2RH (Level-2 Routing Header)

100x Reserved

1010 Logical Address

1011 Symbol (or Option)

A symbol (or option) is a MessageWay optional field that is included, in addition to the regular header, in order to convey specific information from the source node to the destination node (or one of the intervening nodes in the packet traversal path). This capability is envisioned to be useful for enabling future MessageWay extensions, such as security and network management.

These Symbols could appear anywhere before the EEP-header, intermixed with L2RHs. EEP-header-options are only permitted at the end of the EEP-header. One bit of the EEP-header is reserved to indicated the presence of options (f = 1). An option is always a multiple of 64-bits and is in the typical Internet type-length-value (TLV) format.

During the next section of the meeting Tony Skjellum (Mississippi State University) and Scott Michel (UCLA) each presented his group's MessageWay implementation plan and status. Tony's group is doing a preliminary implementation of MessageWay on UDP, with a follow-on implementation targeted for their heterogeneous SAN network of Myrinet and ATM links.

Tony sees three groups of MessageWay Application Programming Interfaces (APIs): Group-1 API to mimic the standard closely, Group-2 API to provide end-to-end reliable transfer, and Group-3 API to include security and realtime support.

Scott's group (at UCLA) is doing a similar MessageWay implementation on their Myrinet networks that are interconnected via ATM.

Kent Koeninger (of Cray Research) gave a presentation of the SAN protocols being considered by Cray Research and their need for megapackets (packets with lengths in the hundreds of megabytes). Cray uses GigaRing, a bidirectional ring network based on the Scalable Coherent Interface (SCI) IEEE standard, to connect its supercomputers in a gigabyte/second/link SAN. Cray wants megapacket capability in the transport layer because most of their supercomputer-to-supercomputer data flow is file transfers rather than messages, for which large packets are more efficient. Cray is looking at several potential protocols, including MessageWay and High-Performance Parallel Interface (HIPPI) Framing Protocol (HIPPI-FP). Kent recommended that the MessageWay working group review the HIPPI-FP specification (ANSI X3.210-1992, 13 April 1994.).

Danny closed the meeting by summarizing the near-term goals of the working group. First, the group members need to review and comment on the header changes which Danny will distribute in about two weeks. Second, MSU and UCLA need to continue their MessageWay implementation tasks. And, third, Danny needs to begin definition of the Resource Discovery and Allocation Protocol.

The next MessageWay working group meeting will be in June 1996 at IETF'36.