2.3.15 PacketWay (pktway)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


Danny Cohen <Cohen@myri.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion: pktway@isi.edu
To Subscribe: http://WWW.ERC.MsState.Edu/packetway/mail-list.html
In Body: use above URL to subscribe/unsubscribe
Archive: ftp://ftp.isi.edu/pktway/pktway.mail

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.

PktWay 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 PktWay would be able to use PktWay between heterogeneous processors as if they were all on a single SAN.

PktWay would be designed to provide interoperability among closely located heterogeneous processors at high speed. Pktway will sacrifice scalability and some generality for high performance. Hence, PktWay 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, PktWay will be above the various SANs (such as RACEway and Paragon) and below IP.

PktWay will define separately:

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

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

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 PktWay.

Intellectual Property

All the work that has been performed until now on PktWay is in the public domain. The PktWay Working Group will only handle public domain information. All the members of the PktWay 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:



Submit initial draft specification for the PktWay-EEP (End-to-End Protocol) as an Internet-Draft.



Conduct interoperability demo of the PktWay-EEP (between 2 or 3 heterogeneous systems).

Sep 97


Submit initial draft specification for the PktWay-RRP (Router-to-Router Protocol) as an Internet-Draft.

Sep 97


Submit updated version of the PktWay-EEP (End-to-End Protocol) as an Internet-Draft.

Oct 97


Conduct Interoperability demo of the PktWay-RRP between 2 or 3 heterogeneous systems.

Nov 97


Submit PktWay-RRP Internet-Draft to IESG for consideration as a Proposed Standard.

Dec 97


Submit initial draft specification of the PktWay-REDAP (Resource Discovery and Allocation Protocol) as an Internet-Draft.

Mar 98


Conduct interoperability demo of the PktWay-REDAP between 2 or 3 heterogeneous systems.

Apr 98


Submit PktWay-REDAP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 98


Review Status of the WG. Revise charter or shutdown.


No Request For Comments

Current Meeting Report

Minutes of the PktWay WG Meeting

Reported by Marc Fidler and Mark Littlefield

Danny Cohen opened the meeting by asking all attendees introduce themselves and provide their background.

Danny next presented an overview of PacketWay and the meeting agenda that included:

I. Status of the Documents
II. PktWay and SRVLOC
III. Interoperability Testing
IV. MPI over PktWay

I. Status of the Documents

Thomas Narten (AD-INT) iterated the need to accelerate the work on the various documents, which are the expected delivery of the PktWay-WG. Thomas also provided much needed guidance about various aspects of the required work.

A number of document action items were discussed. The PacketWay specification is now split into multiple documents:

1. EEP The goal is to finish editing the document by the end of the month and submit for proposed standard status by the end of September, including a two-week last-call period.
2. The EEP handling of destination-designation (using Hoffman Coding) has to be better explained than the way it is in the current document.
3. The EEP document will have a new section about address assignment, which will be a recommendation, not a part of the PktWay standard (just as IP address assignment is NOT a part of RFC0791).
4. The enumeration appendix will be removed into a separate document, to be eventually maintained by IANA.
5. RRP This document will be split into three documents:

The enumeration appendix will be removed from the RRP document and a separate document created as mentioned above).

The goal is to submit the RRP documents for proposed standard status by the December IETF meeting.

Marc Fidler and Robert George suggested adding to the PktWay standard a "compressed header" of 8B only. The consensus was that such a compressed PacketWay header should be proposed in a separate document (probably as a new version of the EEP).

Robert George proposed a certain format for the "compressed header" which he will circulate soon via a message to the mailing list.

The following milestones were judged by the working group as realistic:

· Aug-97 EEP interoperability demo (done, between MSU and LMMS)
· Sep-97 Submit the updated EEP Internet-Draft as a Proposed-Standard
· Sep-97 Submit the RRP specification as an Internet-Draft
· Oct-97 Demo test interoperability of the RRP
· Nov-97 Submit the updated RRP as a Proposed-Standard
· Dec-97 (IETF-DC) Submit initial specification of the PktWay REDAP
· (Resource Discovery and Allocation Protocol) as an Internet-Draft
· Mar-98 Demo the PktWay REDAP
· Apr-98 Submit the updated REDAP as a Proposed-Standard

II. PktWay and SRVLOC

Danny reported about the differences between SRVLOC and the way PktWay handles CAPAbilities. In spite of the differences, some coordination is planned between the two working groups. PktWay will add to its capabilities a SRVLOC-server, and some effort will be made to unify the capabilities code. Danny will work on it with Erik Guttman of SUN, the co-chair of the SRVLOC-WG.

III. Interoperability Test

Robert George gave a presentation on PacketWay interoperability testing between Mississippi State University and Sanders. Successful testing of level A (EEP) fields was outlined. The implementations of MSU and LMMS not only were independent, but also use different computing models, as MSU maximizes the share of the host in implementing PktWay, whereas LMMS minimizes it, pushing tasks to the network interface processors.

This test covered most of the EEP features, but not all. Among the features that were not tested yet are the endianness field, padding length, symbols, and priority.

The interoperability test was very successful.

Robert then presented a specific proposal for a compressed PktWay header. The header was 8 bytes in length as opposed to the 16-byte EEP header. It was requested that this header be sent to the PacketWay reflector to solicit comments from interested parties. Robert also mentioned that the working group plans to commence RRP interoperability testing by October.

Since Robert already described the interoperability tests conducted with LMMS, Marc Fidler (of LMMS) did not deliver the presentation that he prepared of the same tests. Marc reiterated the need to clean up the PktWay documents.

IV. MPI over PktWay

Shane Hebert gave a presentation dealing with the commercial need for PacketWay. He detailed MPI-Software-Technology's desire for PacketWay, along with the value of an IETF standardization for PacketWay. In summary, Danny reiterated the need to push the EEP document through editing, while, in the process, work on the RRP documents. All were encouraged to use the mailing list (the "PktWay-reflector"). Danny thought that something was broken with the current reflector. He apologized for it, and promised to get it fixed soon.


None Received

Attendees List

go to list

Previous PageNext Page