As per Relevance of the word indicate, we have this rfc below:
Network Working Group P.
Request for Comments: 1622
Category: Informational May 1994
Pip Header
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
During 1992 and 1993, the Pip internet protocol, developed
Bellcore, was one of the candidate replacments for IP. In mid 1993,
Pip was merged with another candidate, the Simple Internet
(SIP), creating SIPP (SIP Plus). While the major aspects of Pip--
particularly its distinction of identifier from address, and its
of the source route mechanism to achieve rich routing capabilities--
were preserved, many of the ideas in Pip were not. The purpose
this RFC and the companion RFC "Pip Near-term Architecture" are
record the ideas (good and bad) of Pip
The remainder of this document is taken verbatem from the Pip
memo of the same title that existed when the Pip project ended.
such, any text that indicates that Pip is an intended replacement
IP should be ignored
Pip is an internet protocol intended as the replacement for
version 4. Pip is a general purpose internet protocol, designed
handle all forseeable internet protocol requirements.
specification defines the Pip header processing for Routers
Hosts
I want to individually acknowledge Rob Coltun, Steve Deering,
Govindan, Joel Halpern, John Ioannidis, Chris Petrilli, Bob Smart
and Zheng Wang. I want also to acknowledge the many people from
Pip working group who have participated in developing Pip. Finally
I want to acknowledge the SIP protocol (or, more accurately,
people behind the SIP protocol) for providing certain good ideas
Francis [Page 1]
RFC 1622 Pip Header Processing May 1994
All functions in this specification are mandatory
1.
Pip is an internet protocol intended as the replacement for
version 4. Pip is a general purpose internet protocol, designed
handle all forseeable internet protocol requirements.
specification defines the Pip header processing for Routers
Hosts
The design of Pip is fundamentally different from that of
internetwork protocols. Pip is designed to be as general
possible, but without significantly compromising performance
Because of Pip's generality, it can handle forseeable routing
addressing requirements. It is hoped that it will be able to
most if not all future routing and addressing requirements
There are many detailed aspects of Pip that provide this
that are not discussed here. It is useful, however, to mention
general aspect. That is, Pip strives to remove as much "
semantics" from the base specification as possible. Pip defines
packet header and forwarding rules that can include many
functional semantics (that is, routing, addressing, and
paradigms). Therefore, the reader may often find him or
asking "But how do you do foo with Pip?" The answer to this sort
question belongs in companion documents to the basic Pip spec
Pip can be thought of as a mechanism for triggering actions in
and routers, just as a machine language can be thought of as
mechanism for triggering actions in CPUs. The machine language
no functional semantics outside of the specific actions it
(move this register, write that memory location, etc.). But,
machine language is a very powerful tool upon which
semantics are built. Likewise, Pip is a powerful tool upon
routing, addressing, and flow functions can be built
Francis [Page 2]
RFC 1622 Pip Header Processing May 1994
2. Pip
The Pip header is partitioned into three parts, the Initial Part,
Transit Part, and the Options Part
+===========================+
| Initial Part |
+===========================+
| Transit Part |
+===========================+
| Options Part |
+===========================+
| |
| Payload |
| |
Each part falls on a 32-bit boundary (as indicated by the
lines shown), and the Transit Part falls on a 64 bit boundary
The concept of tunneling in an integral part of Pip. Pip
tunneling by encapsulating the Transit Part of the Pip header
another Transit Part. Therefore, when tunneling, there is
Transit Part for each (nested) tunnel
+===========================+
| Initial Part |
+===========================+
| Transit Part |
+===========================+
| Transit Part |
+===========================+
.
.
.
+===========================+
| Transit Part |
+===========================+
| Options Part |
+===========================+
Because each Transit Part has only what is necessary for
forwarding and handling, this method of tunneling is
efficient in terms of packet size
Francis [Page 3]
RFC 1622 Pip Header Processing May 1994
2.1 Initial
The Initial Part is formatted as shown in Figure 1.
length, in
+===========================+
| Version Number = 8 | 4
+---------------------------+
| Sub-Version | 4
+---------------------------+
| Options Offset | 8
+---------------------------+
| Options Contents | 8
+---------------------------+
| Options Present | 8
+===========================+
| Packet SubID | 16
+---------------------------+
| Protocol | 16
+===========================+
| Dest ID | 64
+===========================+
| Source ID | 64
+===========================+
| Payload Length | 32
+===========================+
| Host Version | 8
+---------------------------+
| Payload Offset | 8
+---------------------------+
| Hop Count | 16
+===========================+
Figure 1: Initial
An explanation of each field follows
2.1.1 Version
The first octet is divided into two 4-bit fields, the Version and
Sub-Version. The Version field is set to be 8, and is meant to
version 8 of IP. (As of this writing, this is an experimental
assigned for development of Pip.) Thus, all encapsulation
defined for IP can work for Pip as well
As long as the Version field is 8, the Initial Part and Options
of the Pip Header is as specified in this standard. (In other words
the Sub-Version field refers only to the Transit Part.)
Francis [Page 4]
RFC 1622 Pip Header Processing May 1994
By doing this, we allow the Transit Part of the Pip Header to
completely without necessarily requiring a host to understand the
Transit Part. If a host receives a Pip header with a Version
of 8 and an unknown Sub-version number, the host does not try
parse the Transit Part at all, rather it processes only the
Part and the Options Part. (By using the Pip Header Protocol
format Pip Headers, a host can be made to formulate the right
Part, even though the host doesn't understand the semantics of
Transit Part. This allows radical migration of the Transit
while potentially not requiring changes to hosts.)
If a host or a router receives a packet with an unknown
number, the packet is silently discarded
The Sub-Version field is set to the value 0 for the version of
defined in this specification. As long as the Sub-Version number
0, the Transit Part is as specified in this standard. Any
received by a router with a Version number of 8 and an unknown Sub
Version number is silently discarded
2.1.2 Options
The Options Offset indicates the position of the Options Part.
unit of measure of the Options Offset is 32-bit words, counting
first word of the Pip Header as word 0.
2.1.3 Options
This field indicates how the Options Present field should
interpreted. Each bit of the Options field indicates if each of
to eight options is present in the Options Part. The
Contents field indirectly indicates which option each bit of
Options Present field refers to. We say indirectly because
mapping referred to by the Options Contents field is stored locally
In other words, without additional information (the mapping), it
not possible to examine the Options Contents field and know
option each bit of the Options Present field refers to
Any of 256 possible Options Contents values can be active at a
time. (Note that the means by which the meaning of the
Contents values are assigned and conveyed to routers and hosts
outside the scope of this specification.)
Francis [Page 5]
RFC 1622 Pip Header Processing May 1994
2.1.4 Options
This field indicates which of the Options indicated by the
Contents field are actually present in the Options Part. Each bit
this field refers to a single option type. The mapping of each
to its' option type is determined by the Options Contents field
For instance, assume that the Options Contents field indicates
bit 0 of the Options Present field refers to the PDN Address option
that bit 1 of the Options Present field refers to the foo option,
that bit 2 of the Options Present field refers to the
option. (As of this writing, there is only one option. Until
are more than eight options, there is no need to define more than
Options Contents values.)
In this case, a value of 101 in the Options Present field
that the PDN Address and Fragmentation options are present in
Options Part, and that the foo option is not present
Note that an Options Present value of 0 indicates that there are
options present, regardless of the value of the Options
field. Note also that no more than 8 options, not including
default first option (the Options Descriptor), can be present in
Options Part
The Options Contents/Options Present method of processing
allows for efficient processing of options. First, a router
ignore any options that may be present but that do not impact it (
instance, a router not attached to a PDN need not consider the
Address option). Second, the desired option can be very
retrieved, because the first option, the Options Descriptor option
contains the offset of each of the up to eight options indicated
the Options Present field
2.1.5 Packet
This field is used by Pip hosts to correctly associate received
messages with local control blocks. This is necessary because
semantics of the Transit Part can change while a packet is
transit. Therefore, a router sending a PCMP message
necessarily provide all of the information needed by the Pip host
correctly identify the context of the received message (that is
which "packet flow" it is identified with).
A PCMP message uses the Protocol, Source ID, Dest ID, and
SubID to define the PCMP messages context. It is not sufficient
use just Protocol, Source ID, and Dest ID, because two hosts
the same protocol between them may have multiple "flows",
Francis [Page 6]
RFC 1622 Pip Header Processing May 1994
instance, a data flow, a video flow, and an audio flow in the case
multi-media. Each flow may have a different Transit Part, and
different paths. Therefore, the Packet SubID field is needed
further differentiate
2.1.6
Indicates the protocol header found in the payload. The values
this field are the same as those used for IPv4.
2.1.7 Dest
The Dest ID field indicates the Pip ID of the final recipient of
Pip packet. This field is examined by both hosts and routers
When a Pip System processes the Routing Directive (RD), it
determine that it needs to examine the Dest ID for
processing. This may happen both when a host or router receives
Pip packet destined for itself, or when a router receives a
that should be forwarded based on Dest ID (as indicated by the RD).
When a Pip system determines at forwarding time that a packet
destined for itself, it checks the Dest ID to verify if that
is destined for it. If the complete Dest ID matches one of its
Pip IDs, then the packet is for it, and is passed to the
indicated by the Protocol field (in the Host Part). (The Pip
may of course wish to check a security option before passing a
to an upper layer.)
If the complete Dest ID field does not match one of its own IDs,
an ID/RD Mismatch PCMP message is sent to the source of the packet
as indicated by the Source ID and potentially source information
the RD. The purpose of this message is to flush the ID to RD
in the source Pip host
2.1.8 Source
This is the Pip ID of the source of the packet. It is passed
upper layers for the purposes of identifying the context for
packet
2.1.9 Payload
The Payload Length gives the length of the Pip packet payload
units of 8 bits. The Payload Length does not include the length
the Pip header
Francis [Page 7]
RFC 1622 Pip Header Processing May 1994
2.1.10 Host
The Host Version field indicates what "version" of Pip software
sending host has implemented. This is to allow a host to inform
router which ancillary protocols/messages the host is able to accept
It is envisioned that over time, new host functions will
developed. Different hosts will install these new functions
different times. This field allows routers to know what
the host can and cannot handle
2.1.11 Payload
The Payload Offset indicates the position of the Payload Part.
unit of measure of the Payload Offset is 32-bit words, counting
first word of the Pip Header as word 0.
If a Pip system encapsulates a Transit Part in another Transit Part
then the Payload Offset is increased by the length of the new
Part
2.1.12 Hop
The Hop Count is decremented by every router that forwards the
packet. If a system receives a Pip header with a Hop Count equal
0, and is not the recipient of the packet, then the packet
discarded and a PCMP Destination Unreachable is routed to the
indicated by the Routing Directive. (In other words, a host
legally receive a Transit Part with a Hop Count of 0, and indeed
host doesn't look at the Hop Count field upon reception.)
Francis [Page 8]
RFC 1622 Pip Header Processing May 1994
2.2 Transit
The Transit Part is formatted as shown in Figure 2.
length, in
+===========================+
| Reserved | 16
+---------------------------+
| Transit Part Offset | 8
+---------------------------+
| HD Contents | 8
+===========================+
| Handling Directive (HD) | 32
---------------+===========================+
^ | FTIF Offset | 8
| +---------------------------+
| | RC Contents | 8
| +---------------------------+
| | Routing Context (RC) | 16
Routing +===========================+
| FTIF 1 | 16
Directive +---------------------------+
| | FTIF 2 | 16
| +---------------------------+
| .
| .
| .
| +---------------------------+
| | FTIF N | 16
| +---------------------------+
v | Padding |
---------------+===========================+
Figure 2: Transit
An explanation of each field follows
2.2.1 Transit Part
This field gives the position of the first word of the next
Part. The unit of measure of the Transit Part Offset is 32-
words, counting the first word of the current Transit Part as word 0.
If there is no next Transit Part, then this field is written as
0's
Francis [Page 9]
RFC 1622 Pip Header Processing May 1994
2.2.2 HD
The HD Contents field indicates how the Handling Directive (HD)
should be interpreted. The HD field is divided into multiple fields
each representing a different handling function. Each
field in the HD is called an HD Unit (HDU). The Options
field indirectly indicates which HDUs are in the HD field, and
they are. We say indirectly because the mapping referred to by
HD Contents field is stored locally. In other words,
additional information (the mapping), it is not possible to
the HD Contents field and know what the HDU locations are
Any of 256 possible HD Contents values can be active at a given time
(Note that the means by which the meaning of the HD Contents
are assigned and conveyed to routers and hosts is outside the
of this specification.)
2.2.3 Handling Directive (HD
The HD is a general purpose field used for the purpose of
special packet handling by a Pip system. The HD field does
influence a Pip router's next hop choice for a Pip packet, nor
it influence a Pip host's determination as to whether the Pip
is destined for it. Examples of special packet handling would
"low priority queueing", or "high priority discard", etc. (Note
the Transit Options also influence "handling", in the sense
handling is essentially defined here to mean "anything that is
routing. The HD field, though, is intended for the most common
of handling--handling that is expected to be in a
percentage of packets.)
Both hosts and routers use the HD field. (Hosts may make use of
HD field for packet handling for both incoming and outgoing packets.)
There is a complete distinction between the syntax and the
of the HD field. (This can be contrasted with, for instance, IP
which couples the semantics and syntax of the TOS bits. That is,
IP specification itself determines, to a first degree, how the
bits are interpreted.) Each Pip system can modify the
meaning of the HD, for instance, by increasing or decreasing
queueing priority of a packet. This is called packet tagging
From an abstract modeling perspective, the HD is handled as follows
1. Extract the semantic meaning(s) (the handling
associated with the HDUs) from the HD field. Transmitting
hosts determine the semantic meaning by some other means, such
the upper layer protocol. If the receiving system
Francis [Page 10]
RFC 1622 Pip Header Processing May 1994
multiple Pip headers, then the HD semantics are extracted from
lowest Pip header for which it is not the target (see example
tunneling below).
2. Handle the Pip packet according to those instructions. In
cases, it is possible that the Pip system does not understand
semantics of one or more HDUs of the HD field. For each HDU
semantics are not understood, however, the pip system at
knows whether to 1) pass the HDU on untouched, 2) set it to
0s, 3) set it to all 1s, 4) discard the packet silently, or 5)
discard the packet with a PCMP HDU Not Understood packet
3. Modify the semantic meaning if necessary. Note also that if
Pip packet is replicated for multicast, each packet has its
semantics modified individually. .LP .in 3 2.2.4 Tunneling .
Consider two Pip systems, X and Y, separated by one
intermediate Pip systems. X wishes to tunnel a Transit Part to Y
Y is therefore the target system of the tunnel. A Transit Part
arrives at X. In order to forward the Transit Part to Y,
encapsulates He in another Transit Part, Hy. Y is the
system for Transit Part Hy. X sets the HD of He to what it
have been if Y was directly connected to X (that is, there were
intermediate Pip systems between X and Y). Further, it
intended that Y will derive its HD semantics from the HD
Transit Part He, not Transit Part Hy. .sp .
----0-----o-----o-----o-----o-----0----
X I J K L
Now consider the operation of Pip system L (the previous hop
to Y). When L forwards the packet to Y, it may either
the packet (in the knowledge that Y is the target for Hy), or
decapsulate the packet. Either way, L derives its HD semantics
the HD of Transit Part Hy
If L does not decapsulate the Transit Part, then it is as though I
J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y
stripping the "subnetwork" header (Hy) off before processing the
Transit Part (He). If L does decapsulate the Transit Part, then
from Y's perspective, it is essentially as though Y were
connected to X
Francis [Page 11]
RFC 1622 Pip Header Processing May 1994
2.2.5 Routing Directive (RD
The RD consists of the Routing Context (RC), the RC Contents,
FTIF Offset, and a series of zero or more FTIFs (Forwarding
Index Fields). This series of FTIFs is called the FTIF Chain.
sole purpose of the RD is to determine how to forward the
packet--the RD does not influence handling in any way
Figure 3 illustrates the decision process for forwarding the
packet
+---------+(next level RC
(decapsulate)| |
|
|<--------RC----------------->
| / | | IF Offset
| | |
| |
|<------|---FTIF------------->
| | / :
| |<- :(repeatedly...)
| | :
| |
|<------|---FTIF------------->
| / |
|<- |
v
DestID-------------->
Figure 3: Forwarding
Figure 3 is interpreted as follows. The FIB is the
Information Block. The FIB contains all the information needed
forward a packet, and may contain multiple next hop (for multicast).
This information includes 1) the outgoing interface, 2) how
encapsulate the packet, including lower-layer address(es) (
lower-layer address(es) along with the outgoing interface
the next hop Pip system), 3) whether and how to tunnel, 4) how
modify the semantics of the HD and RC, and how to modify the
Offset. The goal of the forwarding algorithm is to reach
appropriate FIB
The directed lines in Figure 3 start at the RC and, through
possible paths, reach a FIB. These lines represent the
information that can influence the forwarding decision (that is,
FIB chosen). For instance, there is no way to reach a FIB
Francis [Page 12]
RFC 1622 Pip Header Processing May 1994
first examining the information in the RC. However, it is
to identify a FIB by considering only the information in the RC (
indicated by the directed line leading directly right from the RC).
Based on the information in the RC, it is also possible to
that the Transit Part must be decapsulated, and 1) the RC of the
Transit Part be processed (the line leading directly left), 2)
FTIF indicated by the FTIF Offset is processed (the line leading
and right), or 3) the Dest ID is processed (the line leading down
lest).
Likewise, when considering the value of an FTIF (in addition to
information already considered), the resulting action may be that 1)
a FIB is identified, 2) the Transit Part is decapsulated, 3)
subsequent FTIF is processed, or 4) the Dest ID is processed
The RC is handled similarly to the HD. The RC Contents
indicates how the RC should be interpreted. While the RC
constructed similarly to the HD in the sense that it consists
multiple fields, the RC can be interpreted as a flat field in-so-
as forwarding a Pip packet is concerned, whereas the HD cannot
Thus, in a mechanical sense, the RC Contents can be viewed as
index into a table that returns a pointer to another table (
rcTable), which is indexed by the RC itself. (Or, the combined
Contents/RC can be viewed as a single large index into a
table, etc.)
The FTIF Offset field indicates which FTIF is active. The
FTIF is the one that is used to index the forwarding table
by the RC Contents/RC. An FTIF Offset value of 0 means that
first FTIF is active, an FTIF Offset value of 1 means that the
FTIF is active, and so on. If there are no FTIFs, then the
Offset has no meaning, and can be any value. In this case, the
field itself will indicate how to forward the packet
The FTIF Chain is padded out to a 32-bit boundary. Note that
can be more than 16 bits of padding (for instance, if it is
to pad out to a 64-bit boundary). The padding is ignored
receipt, and can be transmitted as any value (that is, it does
have to be any specific pattern of 0's or 1's).
Note that a single "number" in the FTIF chain may in fact be
than 16 bits in length. In this case, the number can be encoded
multiple FTIFs with no loss of generality. It is only required
in all cases a multiple FTIF number be distinguishable from a
FTIF number
Francis [Page 13]
RFC 1622 Pip Header Processing May 1994
2.2.6 Router RD Forwarding
This section describes the forwarding algorithm for a Pip router
1. Using the value of the RC field as an index, retrieve one of
following instructions (steps 2 - 5) from the rcTable
by the RC Contents
2. If the instruction is decapsulate, then decapsulate the
Part and re-execute step 1 using the next Transit Part
3. If the instruction is forward, then retrieve the
Forwarding Information Block (FIB), and go to step 12.
4. If the instruction is to examine the Dest ID, then retrieve
FIB associated with the Dest ID, and go to step 12.
5. If the instruction is to examine the FTIF Chain, then retrieve
forwardingTable indicated by the rcTable entry, and continue on
step 6.
6. Using the value of the currently active FTIF (this is the
indicated by the FTIF Offset if this is the first FTIF examined
as an index, retrieve one or more of the following
(steps 7 - 10) from the forwardingTable identified in step 5
step 10.
7. If the instruction is decapsulate, then decapsulate the Pip
and re-execute step 1 using the new header (this is the same
step 2).
8. If the instruction is forward, then (possibly additionally
retrieve the associated FIB, and go to step 12 (this is the
as step 3).
9. If the instruction is to examine the Dest ID, then retrieve
FIB associated with the Dest ID and go to step 12 (this is
same as step 4).
10. If the instruction is to examine the next FTIF, then,
to the information in the current forwardingTable entry,
the current FTIF and choose a new forwardingTable
11. Make the next FTIF the current FTIF and go to step 6.
12. The FIB contains a set of potential recipients for the
packet, including next hop Pip systems (both directly
and at the end of Pip tunnels) and the upper layer of the
Francis [Page 14]
RFC 1622 Pip Header Processing May 1994
system. Taking into consideration 1) the incoming interface, 2)
the previous hop Pip system if known (as determined by
lower-layer source address and incoming interface), and 3)
potentially other local information (such as congestion
outgoing queues), prune the set of potential recipients. (
may result in no pruning having taken place or in every
next hop having been pruned.)
13. For each remaining next hop, format a Pip header by modifying a
the RC, b) the current FTIF, c) the FTIF Offset (to point to 1)
the FTIF pointed to in the received RD, 2) the current FTIF, 3)
the Nth FTIF counting from the 0th FTIF, or 4) the Nth
counting forwards or backwards from the current FTIF) and d)
Pip header encapsulations, according to the information in
FIB, and transmit the packet to the recipient (either a next
or upper layer).
2.3 Options
The Option Part is formatted as shown in Figure 4.
+===========================+
| Options Descriptor | 64
+===========================+
| Option 2 |
+===========================+
| Option 3 |
+===========================+
.
.
.
+===========================+
| Option N |
+===========================+
Figure 4: Options
Every Option is at least one 32-bit word in length, and ends on
32-bit word boundary. Because the type of each option is known
the Options Contents field, there is no need to indicate the
type in the options field themselves. Thus, there is no
format among the options--each option has its own format.
individual options are defined in another specification
Francis [Page 15]
RFC 1622 Pip Header Processing May 1994
2.3.1 Options
The Options Descriptor option gives the offset of each option in
Options Part. The Options Descriptor consists of eight eight-
Option Position fields, each of which gives the position of up
eight options (there can be no more than 8 Options Part). Each
the Option Position fields correspond to one of the bits in
Options Present field. The unit of measure of each Option
is 32-bit words, counting the first word of the Options Part as
0. The high order Option Position field corresponds to the
order bit in the Options Present field
Security
Security issues are not discussed in this memo
Author's
Paul
NTT Software
3-9-11 Midori-cho Musashino-
Tokyo 180
Phone: +81-422-59-3843
Fax +81-422-59-3765
EMail: francis@cactus.ntt.
Francis [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
