NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97
Chair(s):
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:
* 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:
Done |
|
Submit initial draft specification for the PktWay-EEP (End-to-End Protocol) as an Internet-Draft. |
Done |
|
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. |
Internet-Drafts:
· The End-to-End (EEP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters
· Part-1 of The Router-to-Router (RRP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters
No Request For Comments
Minutes of the PacketWay (PktWay) WG
The PacketWay working group met at IETF'40, in Washington DC, on Monday, December 8th. Danny Cohen opened the meeting.
Several issues were discussed.
· The comments provided by Greg Chesson regarding the last-call for the EEP document (draft-ietf-pktway-protocol-eep-spec-02). Danny will post them on the PktWay reflector, and will prepare a written response. Comments from all were solicited.
· It was suggested that the EEP document and the RRP documents shall stay separate (as already done) but will be submitted together, "in parallel." This was suggested because several issues mentioned in the EEP documents (e.g., resource discovery) depend on what is defined (and specified) in the other documents.
· It was suggested that PktWay will be labeled as "Experimental" Standard (instead of a "Standard" standard). This was suggested because it is felt that PktWay is not as mature as most of the "main line" activities in the IETF. Feedback about making PacketWay an "Experimental" Standard instead of a "Standard" Standard is solicited. Marc Fiddler brought up the point that for some of their customers are less likely to invest in a product labeled "Experimental".
· Marc Fidler of Sanders (LMMS) presented the status of Sanders PacketWay Implementation.
· Matthew P. Gleeson of MSU (Mississippi State University) presented the status of MSU PacketWay Implementation.
· Craig Lund (Mercury) iterated that it would be very useful to have PktWay implemented on any SAN, in addition to the existing two implementations on Myrinet.
Action Items:
1. Post Greg Chesson comments
2. Post a response to them
3. Post the RRP-2 document
4. Advance the EEP+RRP1+RRP2 documents together.
None Received