Pip Header Processing
RFC 1622

Document Type RFC - Historic (May 1994; No errata)
Last updated 2017-12-01
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1622 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         P. Francis
Request for Comments: 1622                                           NTT
Category: Informational                                         May 1994

                         Pip Header Processing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Preamble

   During 1992 and 1993, the Pip internet protocol, developed at
   Bellcore, was one of the candidate replacments for IP.  In mid 1993,
   Pip was merged with another candidate, the Simple Internet Protocol
   (SIP), creating SIPP (SIP Plus).  While the major aspects of Pip--
   particularly its distinction of identifier from address, and its use
   of the source route mechanism to achieve rich routing capabilities--
   were preserved, many of the ideas in Pip were not.  The purpose of
   this RFC and the companion RFC "Pip Near-term Architecture" are to
   record the ideas (good and bad) of Pip.

   The remainder of this document is taken verbatem from the Pip draft
   memo of the same title that existed when the Pip project ended.  As
   such, any text that indicates that Pip is an intended replacement for
   IP should be ignored.

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, Ramesh
   Govindan, Joel Halpern, 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.  Finally,
   I want to acknowledge the SIP protocol (or, more accurately, the
   people behind the SIP protocol) for providing certain good ideas.

Francis                                                         [Page 1]
RFC 1622                 Pip Header Processing                  May 1994

Conventions

   All functions in this specification are mandatory.

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

Francis                                                         [Page 2]
RFC 1622                 Pip Header Processing                  May 1994

2.  Pip Specification

   The Pip header is partitioned into three parts, the Initial Part, the
   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 double
   lines shown), and the Transit Part falls on a 64 bit boundary.

   The concept of tunneling in an integral part of Pip.  Pip achieves
Show full document text