preliminary draft of pip spec.....
Paul Tsuchiya <tsuchiya@thumper.bellcore.com> Wed, 09 September 1992 17:31 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05579; 9 Sep 92 13:31 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05575; 9 Sep 92 13:31 EDT
Received: from thumper.bellcore.com by NRI.Reston.VA.US id aa01621; 9 Sep 92 13:33 EDT
Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA27412> for ietf-archive@nri.reston.va.us; Wed, 9 Sep 92 13:12:57 EDT
Received: by chiya.bellcore.com (4.1/4.7) id <AA12746> for pip-local@thumper; Wed, 9 Sep 92 13:12:57 EDT
Date: Wed, 09 Sep 1992 13:12:57 -0400
From: Paul Tsuchiya <tsuchiya@thumper.bellcore.com>
Message-Id: <9209091712.AA12746@chiya.bellcore.com>
To: pip@thumper.bellcore.com
Subject: preliminary draft of pip spec.....
Gang,
Below is the preliminary draft of the pip spec.
It is not complete, but has the basic functions and
all of the header formats. I'm releasing now to
just the pip group to get preliminary feedback
before posting a real internet draft......
I'll post this at thumper.bellcore.com:pub/tsuchiya/pipSpec.txt
PX
________________________________________________
Network Working Group P. Tsuchiya
INTERNET-DRAFT Bellcore
September 1992
Pip Header Processing
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
Pip is an internet protocol intended as the replacement for IP
version 4. Pip is a general purpose internet protocol, designed to
handle all forseeable internet protocol requirements. This
specification defines the Pip header processing for Routers and
Hosts.
Acknowledgements
I want to individually acknowledge Rob Coltun, Steve Deering, John
Ioannidis, Chris Petrilli, Bob Smart, and Zheng Wang. I want also to
acknowledge the many people from the Pip working group who have
participated in developing Pip, and to apologize for not naming them
individually.
Conventions
All functions in this specification are mandatory.
Introduction
Pip is an internet protocol intended as the replacement for IP
version 4. Pip is a general purpose internet protocol, designed to
handle all forseeable internet protocol requirements. This
specification defines the Pip header processing for Routers and
Pip WG, Expires March. 1, 1993 [Page 1]
INTERNET-DRAFT Pip Header September 1992
Hosts.
The design of Pip is fundamentally different from that of previous
internetwork protocols. Pip is designed to be as general as
possible, but without significantly compromising performance.
Because of Pip's generality, it can handle forseeable routing and
addressing requirements. It is hoped that it will be able to handle
most if not all future routing and addressing requirements.
There are many detailed aspects of Pip that provide this generality
that are not discussed here. It is useful, however, to mention one
general aspect. That is, Pip strives to remove as much "functional
semantics" from the base specification as possible. Pip defines a
packet header and forwarding rules that can include many different
functional semantics (that is, routing, addressing, and flow
paradigms). Therefore, the reader may often find him or herself
asking "But how do you do foo with Pip?" The answer to this sort of
question belongs in companion documents to the basic Pip spec.
Pip can be thought of as a mechanism for triggering actions in hosts
and routers, just as a machine language can be thought of as a
mechanism for triggering actions in CPUs. The machine language has
no functional semantics outside of the specific actions it triggers
(move this register, write that memory location, etc.). But, the
machine language is a very powerful tool upon which functional
semantics are built. Likewise, Pip is a powerful tool upon which
routing, addressing, and flow functions can be built.
Definitions
Reverse Routing Directive: The Routing Directive resulting from the
process of reversing the FTIF Chain of the Routing Directive, and
setting the FTIF Offset to point to the FTIF that, before reversing
the FTIF fields, preceeded the FTIF field that had currently been
active.
Pip system: A Pip-capable host or router.
Routing Directive: That part of the Pip header starting with the
Routing Context field and ending with the first Router Option (or
Host Part, if there are no Router Options).
Target system: The Pip system for which the Pip header is intended.
This definition is used in conjunction with tunneling, where an
encapsulated Pip header is "targeted" for a Pip system more than one
internet hop away. In the case where no tunneling is used, the
receiving host is the target system (excepting the case where the Pip
header is in error).
High and Low (in the context of Tunneling): When Routing Pargs are
recursively encapsulated, the "lower" Routing Part encapsulates the
"higher" Routing Part.
Pip WG, Expires March. 1, 1993 [Page 2]
INTERNET-DRAFT Pip Header September 1992
Pip Specification
The Pip header is partitioned into four parts, the Router Part, the
Router Options, the Host Part, and the Host Options:
+===========================+
| Misc Part |
+===========================+
| Router Part |
+===========================+
| Router Options |
+===========================+
| Host Part |
+===========================+
| Host Options |
+===========================+
| |
| Payload |
| |
Each part falls on a 32-bit boundary (as indicated by the double
lines shown). When a router receives a Pip packet, it does not need
to look at Host Part or Host Options for the purposes of non-options
processing packet forwarding and flow handling. Depending on the
Router Option, a router may need to look at the host parts of the Pip
header (for instance, for fragmentation). Routers may, however, wish
to look at the Host parts or even higher layers for the purpose of
filtering, billing, or whatever. When a host receives a Pip packet,
it must look at all parts. The Pip header is designed to make
forwarding and flow handling by routers efficient, but not looking at
"higher layer" information (including the host parts, even though the
host parts are not strictly higher layer in terms of a protocol
identifier and such).
The concept of tunneling in an integral part of Pip. Pip achieves
tunneling by encapsulating the Router Part of the Pip header in
another Router Part. Therefore, when tunneling, there is one Router
Part for each (nested) tunnel:
Pip WG, Expires March. 1, 1993 [Page 3]
INTERNET-DRAFT Pip Header September 1992
+===========================+
| Misc Part |
+===========================+
| Router Part |
+===========================+
| Router Part |
+===========================+
.
.
.
+===========================+
| Router Part |
+===========================+
| Router Options |
+===========================+
| Host Part |
+===========================+
| Host Options |
+===========================+
Because each Router Part has only what is necessary for router
forwarding and handling, this method of tunneling is reasonably
efficient in terms of packet size.
Misc Part
The Misc Part is formatted as below:
length, in bits
+===========================+
| 7 | 4
+---------------------------+
| Sub-Version | 4
+---------------------------+
| Options Present | 1
+---------------------------+
| Options/Host Part Offset | 11
+---------------------------+
| Hop Count | 12
+===========================+
An explanation of each field follows.
Version Numbers
The first octet is divided into two 4-bit fields, the Version and the
Sub-Version. The Version field is set to be 7, and is meant to be
version 7 of IP. Thus, all encapsulation schemes defined for IP can
work for Pip as well. The Sub-Version field is set to the value 0
for the version of Pip defined in this specification.
Pip WG, Expires March. 1, 1993 [Page 4]
INTERNET-DRAFT Pip Header September 1992
Options Present
When the Options Present bit is set to 0, there are no Router Options
present. When the Options Present bit is set to 1, there are Router
Options present.
Options/Host Part Offset
The Options/Host Part Offset indicates the position of the first
non-Routing Part word. The unit of measure of the Options/Host Part
Offset is 32-bit words, counting the first word containing an FTIF as
word 0. That is, if the Options/Host Part Offset is 0, then there is
only one Routing Part, and that Routing Part has no FTIFs. If the
Options Present bit is 1, then the Options/Host Part Offset indicates
the position of the first Router Option. If the Options Present bit
is 0, then the Options/Host Part Offset indicates the position of the
Host Part. Note that if Router Options are present, then the first
Router Option will indicate the position of the Host Part.
If a Pip system encapsulates a Pip Routing Part in another Pip
Routing Part, then the Options/Host Part Offset in the new Routing
Part must be increased by the length of the new Routing Part. This
allows subsequent routers to find the position of the Router Options
easily.
Hop Count
The Hop Count is decremented by every router that forwards the Pip
packet. If a system receives a Pip header with a Hop Count equal to
0, and is not the recipient of the packet, then the packet is
discarded and a PCMP Destination Unreachable is routed to the system
indicated by the Reverse Routing Directive. (In other words, a host
can legally receive a Routing Part with a Hop Count of 0.)
Router Part
The Router Part is formatted as shown in Figure 1.
An explanation of each field follows.
Handling Directive (HD)
The HD is a general purpose field used for the purpose of triggering
special packet handling by a Pip system. The HD field does not
influence a Pip router's next hop choice for a Pip packet, nor does
it influence a Pip host's determination as to whether the Pip packet
is destined for it. Examples of special packet handling would be
"low priority queueing", or "high priority discard", etc.
Both hosts and routers use the HD field. (Hosts may make use of the
HD field for packet handling for both incoming and outgoing packets.)
The HD field makes a complete distinction between the syntax and the
Pip WG, Expires March. 1, 1993 [Page 5]
INTERNET-DRAFT Pip Header September 1992
length, in bits
+===========================+
| Handling Directive (HD) | 32
+===========================+
| Routing Context (RC) | 24
+---------------------------+
| FTIF Length | 2
+---------------------------+
| FTIF Offset | 6
+===========================+
| FTIF 1 | Variable
+---------------------------+
| FTIF 2 | Variable
+---------------------------+
.
.
.
+---------------------------+
| FTIF N | Variable
+---------------------------+
| Padding | Variable
+===========================+
Figure 1: Router Part
semantics of the HD field. (This can be contrasted with, for
instance, IP, which couples the semantics and syntax of the TOS bits.
That is, the IP specification itself determines, to a first degree,
how the TOS bits should be interpreted.) Indeed, each Pip system has
its own interpretation of the HD field, and one Pip system must
modify the HD field to match the next hop Pip system's
interpretation. In addition, each Pip system can modify the semantic
meaning of the HD, for instance, by increasing or decreasing the
queueing priority of a packet.
From an abstract modeling perspective, the HD is handled as follows:
1. Extract the semantic meaning(s) (the handling instructions) from
the HD. Transmitting Pip hosts must determine the semantic
meaning from another source, such as the upper layer protocol.
If the receiving system decapsulates multiple Pip headers, then
the HD semantics are extracted from the lowest Pip header for
which it is not the target (see example on tunneling below).
2. Handle the Pip packet according to those instructions.
3. Modify the semantic meaning if necessary.
4. Map the (potentially new) semantic meaning into the HD syntax
expected by the next hop Pip systems (receiving Pip hosts skip
this step). Note that if the Pip header is to be encapsulated
in another Pip header for the purposes of tunneling, then there
Pip WG, Expires March. 1, 1993 [Page 6]
INTERNET-DRAFT Pip Header September 1992
are two (or more, if multiple encapsulations) next hop systems-
-one at the end of the tunnel (the target system for the encap-
sulating Pip header), and the true next hop. The HD semantics
are mapped into the HD syntax of the appropriate system. Note
also that if the Pip packet is replicated for multicast, the HD
must be individually mapped for each next hop.
Tunneling
Consider two Pip systems, X and Y, separated by one or more inter-
mediate Pip systems. X wishes to tunnel a Routing Part to Y. Y is
therefore the target system of the tunnel. A Routing Part He arrives
at X. In order to forward the Routing Part to Y, X encapsulates He
in another Routing Part, Hy. Y is the target system for Routing Part
Hy. X sets the HD of He to what it would have been if Y was directly
connected to X (that is, there were no intermediate Pip systems
between X and Y). Further, it is intended that Y will derive its HD
semantics from the HD of Routing Part He, not Routing Part Hy.
----0-----o-----o-----o-----o-----0----
X I J K L Y
Now consider the operation of Pip system L (the previous hop system
to Y). When L forwards the packet to Y, it may either decapsulate
the packet (in the knowledge that Y is the target for Hy), or not
decapsulate the packet. Either way, L derives its HD semantics from
the HD of Routing Part He.
If L does not decapsulate the Routing Part, then it is as though I,
J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y is
stripping the "subnetwork" header (Hy) off before processing the true
Routing Part (He). If L does decapsulate the Routing Part, then,
from Y's perspective, it is essentially as though Y were directly
connected to X.
Routing Directive (RD)
The RD consists of the Routing Context (RC), the FTIF Length, the
FTIF Offset, and a series of zero or more FTIFs (Forwarding Table
Index Fields). This series of FTIFs is called the FTIF Chain.
The RC is used to either 1) determine how to forward the Pip packet,
or 2) determine the context within which the FTIF should be
evaluated. In the latter role, the RC can be thought of as selecting
one of multiple forwarding tables, into which the active FTIF is then
used as an index.
The RC is handled similarly to the HD. That is, the syntax and
semantics of the RC are separated. Each Pip system determines its
own syntax for the RC, and knows the syntax for neighbor Pip systems
Pip WG, Expires March. 1, 1993 [Page 7]
INTERNET-DRAFT Pip Header September 1992
so that it can translate the RC appropriately upon transmission.
The FTIF Length field indicates the length of each FTIF in the FTIF
Chain (all FTIFs are the same length). FITFs can be one of four
lengths, 8 bits, 10 bits, 16 bits, and 32 bits. The FTIF Length
field is encoded as follows:
FTIF Length value Actual FTIF length
----------------- ------------------
0 8 bits
1 10 bits
2 16 bits
3 32 bits
The FTIF Offset field indicates which FTIF is active. The active
FTIF is the one that is used to index the forwarding table indicated
by the RC. An FTIF Offset value of 0 means that the first FTIF is
active, an FTIF Offset value of 1 means that the second FTIF is
active, and so on. If there are no FTIFs, then the FTIF Length and
FTIF Offset have no meaning, and can be any value. In this case, the
RC field itself will indicate how to forward the packet.
Note that the FTIF Length concatenated with the FTIF Offset forms a
8-bit value that indicates the exact location of the active FTIF.
Therefore, this 8-bit value can be used as an index into an array
that gives information about the specific location of the active
FTIF.
The FTIF Chain is padded out to a 32-bit boundary. Note that there
can be more than 32 bits of padding (for instance, if it is desirable
to pad out to a 64-bit boundary). The padding is ignored upon
receipt, and can be transmitted as any value (that is, it does not
have to be any specific pattern of 0's or 1's).
When any but the 10-bit FTIF size are used, each FTIF is contiguous
with the previous and subsequent FTIF. When the 10-bit FTIF size is
used, each 32 bit word of the FTIF Chain contains 2 bits of padding
in the leftmost bit positions (the bits that first come in off the
wire) followed by one to three contiguous 10-bit FTIFs. (The only
case where there would be less than three FTIFs is the case where the
end of the FTIF Chain has been reached.)
For example, an FTIF Chain with 4 10-bit FTIFs would come in off the
wire as follows:
padding 2 bits first 32-bit word
first FTIF 10 bits |
second FTIF 10 bits |
third FTIF 10 bits v
padding 2 bits second 32-bit word
fourth FTIF 10 bits |
padding 20 bits v
Pip WG, Expires March. 1, 1993 [Page 8]
INTERNET-DRAFT Pip Header September 1992
This formatting of FTIFs means that no FTIF less than or equal to
32-bits in length straddles a 32-bit boundary. As such, an FTIF of
32-bits or less can always be retrieved by accessing only one 32-bit
word.
Router RD Forwarding Algorithm
This section describes the forwarding algorithm for a Pip router.
1. Using the value of the RC field as an index, retrieve one or more
of the following instructions (steps 2 - 4) from the rcTable. (The
reason that more than one instruction might be retrieved is for the
case where the packet is to be multicast.)
2. If one of the instructions is decapsulate, then decapsulate the Pip
header and re-execute step 1 using the new header.
3. If one of the instructions is forward, then (possibly additionally)
retrieve the associated Forwarding Information Block (FIB), and go
to step 10.
4. If one of the instructions is to examine the FTIF Chain, then (pos-
sibly additionally) retrieve the forwardingTable indicated by the
rcTable entry, and continue on to step 5.
5. Using the value of the FTIF indicated by the FTIF Offset as an
index, retrieve one or more of the following instructions (steps 6
- 8) from the forwardingTable identified in step 4 or step 8.
6. If one of the instructions is decapsulate, then decapsulate the Pip
header and re-execute step 1 using the new header (this is the same
as step 2).
7. If one of the instructions is forward, then (possibly additionally)
retrieve the associated Forwarding Information Block (FIB), and go
to step 10 (this is the same as step 3).
8. If one of the instructions is to examine the next FTIF, then,
according to the information in the current forwardingTable entry,
modify the current FTIF and choose a new forwardingTable.
9. Increment the FTIF Offset and go to step 5.
10. The FIB contains a set of potential recipient for the Pip packet,
including next hop Pip systems (both directly connected and at the
end of Pip tunnels) and the Host Part processing of the local sys-
tem. Taking into consideration the previous hop Pip system (as
determined by the lower-layer source address and incoming inter-
face) and potentially other local information (such as congestion
on outgoing queues), prune the set of potential next hops. (This
may result in no pruning having taken place or in every potential
next hop having been pruned.)
11. For each remaining next hop, format a Pip header by modifying a)
Pip WG, Expires March. 1, 1993 [Page 9]
INTERNET-DRAFT Pip Header September 1992
the RC, b) the current FTIF, c) the FTIF Offset (either with a com-
pletely new value or an addition or subtraction on the current
value) and d) any Pip header encapsulates, according to the infor-
mation in the FIB, and transmit the packet to the recipient (either
next hop or Host Part processing).
Router Options
The Router Options are formatted as shown in Figure 2.
+===========================+
| Router Options Length | 32
+===========================+
| Option 2 | Variable
+===========================+
| Option 3 | Variable
+===========================+
.
.
.
+===========================+
| Option N | Variable
+===========================+
| Router Options Checksum | 32
+===========================+
Figure 2: Router Options
Every Option is at least one 32-bit word in length, and ends on a
32-bit word boundary. Each option is formatted as follows:
length, in bits
+===========================+
| Router Option Type | 8
+---------------------------+
| Option Length | 6
+---------------------------+
| Action if Unrecognized | 2
+---------------------------+
| Option Data | Variable
+===========================+
The Option Type field indicates the type of Option.
The Option Length field gives the length of the option in 32-bit
words.
The Action if Unrecognized (AU) determines what the Pip system should
do if it does not recognize the Option, according to the following
values:
Pip WG, Expires March. 1, 1993 [Page 10]
INTERNET-DRAFT Pip Header September 1992
AU value Action
-------- ------
0 Ignore Option and continue processing
1 Silently discard packet
2 Discard Packet with Notification
Defined Options
The following Options are defined.
Router Options Length
The Options Length option gives the number of 32-bit words comprised
by all Router Options. It has Router Option Type = 1 and Option
Length = 1. The AU is of type 1 (Silently discard packet). The
Option Data is a single 16 bit value, and contains the length, in
32-bit words, of the combined Router Options (including the Options
Length and Options Checksum options).
The Options Length option is always the first option. If any Router
Options are included, the Options Length option must be included.
Router Options Checksum
The Options Checksum option has Router Option Type = 2 and Option
Length = 1. The AU is of type 1 (Silently discard packet). The
Option Data is a single 16 bit value, and contains the checksum
value.
The checksum algorithm is the same as that of IP. That is, the
checksum field is the 16 bit one's complement of the one's complement
sum of all 16 bit words in the header. For purposes of computing the
checksum, the value of the checksum field is zero.
The Options Checksum option is always the last option. If any Router
Options are included, the Options Checksum option must be included.
Fragmentation
The Fragmentation Option has Router Option Type = 3 and Option Length
= 2. The AU is of type 2. The Option Data is formatted as follows:
Pip WG, Expires March. 1, 1993 [Page 11]
INTERNET-DRAFT Pip Header September 1992
length, in bits
+---------------------------+
| |
+=== Identification ===+ 26
+---------------------------+
| Send Max PDU Size | 1
+---------------------------+
| More Fragments | 1
+---------------------------+
| Fragment Offset | 20
+===========================+
The Identification, More Fragments, and Fragment Offset are used
exactly as with IP, with the exception that the Fragment Offset is in
units of 32 bits (not 64 bits, as with IP). That is, the Identifica-
tion field identifies which packet this fragment belongs to. The
More Fragments bit is 1 if there are more fragments, and 0 if it is
the last fragment. The first fragment has offset 0. The Send Max
PDU Size bit is 1 if the fragmenting router should return a Max PDU
Size PCMP packet to the originating host, and 0 if the fragmenting
router should not.
If the Router Options does not contain a Fragmentation Option, then
the packet cannot be fragmented. If fragmentation is necessary to
forward the packet, then the packet is discarded rather than frag-
mented.
When a host creates a Fragmentation Option, it sets the Identifica-
tion field to a value that must be unique for the combination of
Source ID, Dest ID, and Protocol (these fields are all in the Host
Part of the Pip header) for the lifetime of the packet. Each frag-
ment of a fragmented Pip packet must modify the Payload Length field
to accurately indicate the length of the new payload. Each fragment
of a fragmented Pip packet must contain the entire Pip header of the
original (unfragmented) Pip header.
Host Part
The Host Part is formatted as shown in Figure 3.
The fields of the Host Part are defined as follows:
Payload Length
The Payload Length gives the length of the Pip packet payload in
units of 8 bits. The Payload Length does not include the length of
the Pip header.
Protocol
Indicates the protocol header found in the payload. The values for
this field are the same as those used for IPv4.
Pip WG, Expires March. 1, 1993 [Page 12]
INTERNET-DRAFT Pip Header September 1992
length, in bits
+===========================+
| Payload Length | 24
+---------------------------+
| Protocol | 8
+===========================+
| Dest ID | 64
+===========================+
| Source ID | 64
+===========================+
| Packet ID | 16
+---------------------------+
| Host Part Checksum | 16
+===========================+
Figure 3: Host Part
Dest and Source ID
These are the identifiers of the source and destination of the
packet. When a Pip system determines at forwarding time that a
packet is destined for itself (based on the RD), it checks the Source
ID to verify if that packet is destined for it. If the complete Dest
ID matches its own ID, then the packet is for it, and is passed to
the layer indicated by the Protocol field. (The Pip system may of
course wish to check a security option before passing a packet to an
upper layer.)
If the complete Dest ID field does not match its own ID, then an
ID/RD Mismatch PCMP message is sent to the source of the packet. The
purpose of this message is to flush the ID to RD binding in the
source Pip host.
The Source ID indicates the source of a packet. It is passed to
upper layers for the purposes of identifying the context for the
packet.
The following formats are defined for the ID fields:
1. IP address. If the first 4 octets of the ID field is hex 00000001,
then the remaining 4 octets is an IP address.
2. IEEE 802 address. If the first 2 octets of the ID field is hex
0001, then the remaining 6 octets is an IEEE 802 address.
3. X.121 address.......
4. E.164 address.......
5. Others.....
Packet ID
The purpose of the Packet ID is to identify the HD/RD context of the
Pip WG, Expires March. 1, 1993 [Page 13]
INTERNET-DRAFT Pip Header September 1992
packet for the purposes of processing PCMP messages. Since the HD
and RD can change in transit, the Packet ID (in addition to the
Source ID, Dest ID, and Protocol) is required for the system receiv-
ing the PCMP message to know which HD/RD the message pertains to.
The Source ID, Dest ID, and Protocol fields alone are not adequate
for this identification since different packets with the same Source
ID, Dest ID, and Protocol fields may have different HDs or RDs.
When the originator of a Pip header (either a host, or in the case of
tunneling, a router) initially forms the Pip header, it chooses a
Packet ID to associate with that header. This Packet ID is one that
has not been used recently for the Source ID/Dest ID/Protocol combi-
nation. When subsequent identical Pip headers are formed, the same
Packet ID should be used. This field is not used by routers for the
forwarding function. This field is not examined by hosts upon recep-
tion of a Pip header.
Host Options
The Host Options are formatted exactly as the Router Options. The
type field for the Host Options is called the Host Option Type. It
contains different types from the Router Option Type field (that is,
they are separate number spaces). As with the Router Options, the
Options Length and Options Checksum options have Host Option Types 1
and 2 respectively. These options are used in the Host Options
exactly as they are defined for the Router Options.
Other host options needed.....Signature Option (for verifying sender
of packet),.....
Pip WG, Expires March. 1, 1993 [Page 14]
- preliminary draft of pip spec..... Paul Tsuchiya
- Re: preliminary draft of pip spec..... Cyndi Mills
- Re: preliminary draft of pip spec..... Paul Tsuchiya