PacketWay (pktway)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Danny Cohen <Cohen@myri.com>

Internet Area Director(s): 

Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>

Area Advisor: 

Frank Kastenholz <kasten@ftp.com>

Mailing Lists: 

General Discussion:pktway@myri.com
To Subscribe: pktway-request@myri.com
Archive: ftp://ftp.isi.edu/pktway/pktway.mail

Description of Working Group: 

Note: At one time, this was the MsgWay working group 

THE APPROACH 

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:

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

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:

Jul 95 



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

Oct 95 



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

Dec 95 



Meet at 34th IETF to prepare final specification for the PktWay-EEP (End-to-End Protocol).

Dec 95 



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

Feb 96 



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

Mar 96 



Submit final specification of the PktWay-RRP (Router-to-Router Protocol) as an Internet-Draft.

Mar 96 



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

May 96 



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

Jun 96 



Submit final specification of the PktWay-REDAP as an Internet-Draft.

Internet-Drafts: 

· Proposed Specification for the PacketWay Protocol

No Request For Comments 

Current Meeting Report

Minutes of the PacketWay (PktWay) Working Group 

Reported by: Danny Cohen 

The PacketWay working group met at IETF'38 in Memphis on Wednesday, April 9. There were 20 attendees. 

Danny Cohen opened the meeting with a PacketWay overview and the meeting agenda. 

The status of specification was discussed. It is still an Internet-Draft, soon to become a Proposed-Standard. It was agreed that the specification would benefit from a better introduction and an attached tutorial explaining the purpose of PktWay, the approach taken, the rationale behind it, and the like - items that do not belong to the specifications but would help outsiders follow our work. Robert George will work with Danny on that tutorial. 

Danny reported that he did not invite the VMI people (Lockheed-Martin, Advanced Technology Labs) to present their work, even though it relates to PktWay, because it recommends using a protocol that is not open (being defined in a document to which the access is controlled). 

Robert George (of Mississippi State University, MSU) gave a presentation of the work MSU has been doing on the implementation of PacketWay. 

Nathan Doss (of Lockheed-Martin-Sanders) presented the work LM has been doing on the implementation of PacketWay. 

It is expected that within two months interoperability tests between MSU and LM will start. 

Jeff Smith (also of Lockheed-Martin-Sanders) presented his work toward modeling the RRP. 

Slides

None Received Attendees List

Attendees List

TOC