EditorÕs note: These minutes have not been edited.
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 IETF'34), the MessageWay Router-to Router protocol (RRP) is
already specified now (at IETF'35), and the MessageWay Resource
Discovery and Allocation Protocol (REDAP) is planned to be specified
by June 1996 (at IETF'36).
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 e-
mail to the MsgWay-WG.
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.
Attendance List:
NAME COMPANY E-MAIL
Cohen, Danny Myricom cohen@myri.com
Irey, Phil NSWC pirey@relay.nswc.navy.mil
Jones, Rick HP raj@cup.hp.com
Kanoh, Tamotsu ? kanoh@ats.sjk.kdd.co.jp
Kastenholz, Frank FTP Software, Inc. Kasten@ftp.com Knowles, Stev ?
Stev@precision.guesswork.com
Koeninger, R. Kent Cray kentk@cray.com
Lund, Craig Mercury Computer clund@mc.com
Marlow, Dave NSWC dmarlow@relay.nswc.navy.mil
Maury, Jeff ? jfmaury@wtk.suresnes.marben.fr
McMahon, Thom Mississippi State U thom@erc.msstate.edu
Michel, Scott UCLA scottm@cs.ucla.edu
Postel, Jon USC/ISI postel@isi.edu
Seitz, Chuck Myricom chuck@myri.com
Shirley, Fred Sanders fshirley@sanders.com
Skjellum, Tony Mississippi State U tony@cs.msstate.edu
======================================================
========================
Please ack receipt.
Thanks,
Danny