MessageWay (msgway) Charter

NOTE: This charter is accurate as of the 33rd IETF Meeting in Stockholm. It may now be out-of-date. (Consider this a "snapshot" of the working group from that meeting.) Up-to-date charters for all active working groups can be found elsewhere in this Web server.


Internet Area Director(s):

Area Advisor

Mailing List Information

Description of Working Group


Due to dramatic increases in circuits speed the traditional system buses are limited in length (e.g., PCI is limited to 8") and cannot provide the traditional system-wide support. Therefore, the system-wide connectivity is provided by a high performance networks operating in very close quarters, having the generic name System Area Networks (SANs).

Many vendors today use such SANs inside computer platforms to connect processors to IO devices, processors to memory, and processors to processors. Most existing SANs are proprietary, and don't interoperate with each other, not unsimilar to the early stages of LAN development.

In order to be able to interconnect Massively Parallel Processing systems (MPPs) and to interconnect workstations into MPP-like clusters there is a need to unify the SANs and to provide means for interoperability among them.

MsgWay is designed to provide a uniform interface for a wide variety of SANs, such that the higher levels (such as IP) would be able to use SANs in a uniform manner. An IP driver for MsgWay would be able to use MsgWay between heterogeneous processors as if they were all on a single SAN.

MsgWay would be designed to provide interoperability among closely located heterogeneous processors at high speed. Msgway will sacrifice scalability and some generality for high performance. Hence, MsgWay will supplement IP for high performance and for fine granularity of processors.

802.1, the link level control protocol is above LANs, such as the various Ethernets, FDDI, and Token Ring, at Level-2, and below IP, at Level-3.

Similarly, MsgWay will be above the various SANs (such as RACEway and Paragon) and below IP.

MsgWay will define separately:

* End-to-End protocol (and packet format) * Router-to-Router protocol (and packet format) * Resource discovery and allocation

The members of the MsgWay Working Group will design, specify, document, propose, implement, and evaluate the above three protocols that define the MsgWay operation.

The members of the working group will also produce reference software for MsgWay.

Based on initial reactions it is expected that the working group will include members from academia, government, and industry, covering the software, hardware, and communication aspects of MsgWay.


All the work that has been performed until now on MsgWay is in the public domain. The MsgWay Working Group will only handle public domain information. All the members of the MsgWay Working Group will be notified that the working group cannot guard any trade secrets, nor limit the distribution of any proprietary information presented to it.

Goals and Milestones

Jul 95
Submit initial draft specification for the MsgWay-EEP (End-to-End Protocol) as an Internet-Draft.
Oct 95
Conduct interoperability demo of the MsgWay-EEP (between 2 or 3 heterogeneous systems).
Dec 95
Meet at 34th IETF to prepare final specification for the MsgWay-EEP (End-to-End Protocol).
Dec 95
Submit initial draft specification for the MsgWay-RRP (Router-to-Router Protocol) as an Internet-Draft.
Feb 96
Conduct Interoperability demo of the MsgWay-RRP between 2 or 3 heterogeneous systems.
Mar 96
Submit final specification of the MsgWay-RRP (Router-to-Router Protocol) as an Internet-Draft.
Mar 96
Submit initial draft specification of the MsgWay-REDAP (Resource Discovery and Allocation Protocol) as an Internet-Draft.
May 96
Conduct interoperabililty demo of the MsgWay-REDAP between 2 or 3 heterogeneous systems.
Jun 96
Submit final specification of the MsgWay-REDAP as an Internet-Draft.

No Current Internet-Drafts

No Request for Comments