rfc1621.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         P. Francis
Request for Comments: 1621                                           NTT
Category: Informational                                         May 1994


                       Pip Near-term Architecture

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
   Belclore, 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 Header Processing" are to record
   the ideas (good and bad) of Pip.

   This document references a number of Pip draft memos that were in
   various stages of completion.  The basic ideas of those memos are
   presented in this document, though many details are lost.  The very
   interested reader can obtain those internet drafts by requesting them
   directly from me at <[e-mail]>.

   The remainder of this document is taken verbatim 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
   evolve to all forseeable internet protocol requirements.  This
   specification describes the routing and addressing architecture for
   near-term Pip deployment.  We say near-term only because Pip is
   designed with evolution in mind, so other architectures are expected
   in the future.  This document, however, makes no reference to such
   future architectures.





Francis                                                         [Page 1]

RFC 1621               Pip Near-term Architecture               May 1994


Table of Contents

   1. Pip Architecture Overview ...................................    4
   1.1 Pip Architecture Characteristics ...........................    4
   1.2 Components of the Pip Architecture .........................    5

   2. A Simple Example ............................................    6

   3. Pip Overview ................................................    7

   4. Pip Addressing ..............................................    9
   4.1 Hierarchical Pip Addressing ................................    9
   4.1.1 Assignment of (Hierarchical) Pip Addresses ...............   12
   4.1.2 Host Addressing ..........................................   14
   4.2 CBT Style Multicast Addresses ..............................   15
   4.3 Class D Style Multicast Addresses ..........................   16
   4.4 Anycast Addressing .........................................   16

   5. Pip IDs .....................................................   17

   6. Use of DNS ..................................................   18
   6.1 Information Held by DNS ....................................   19
   6.2 Authoritative Queries in DNS ...............................   20

   7. Type-of-Service (TOS) (or lack thereof) .....................   21

   8. Routing on (Hierarchical) Pip Addresses .....................   22
   8.1 Exiting a Private Domain ...................................   23
   8.2 Intra-domain Networking ....................................   24

   9. Pip Header Server ...........................................   25
   9.1 Forming Pip Headers ........................................   25
   9.2 Pip Header Protocol (PHP) ..................................   27
   9.3 Application Interface ......................................   27

   10. Routing Algorithms in Pip ..................................   28
   10.1 Routing Information Filtering .............................   29

   11. Transition .................................................   30
   11.1 Justification for Pip Transition Scheme ...................   31
   11.2 Architecture for Pip Transition Scheme ....................   31
   11.3 Translation between Pip and IP packets ....................   33
   11.4 Translating between PCMP and ICMP .........................   34
   11.5 Translating between IP and Pip Routing Information ........   34
   11.6 Old TCP and Application Binaries in Pip Hosts .............   34
   11.7 Translating between Pip Capable and non-Pip Capable DNS
        Servers ...................................................   35




Francis                                                         [Page 2]

RFC 1621               Pip Near-term Architecture               May 1994


   12. Pip Address and ID Auto-configuration ......................   37
   12.1 Pip Address Prefix Administration .........................   37
   12.2 Host Autoconfiguration ....................................   38
   12.2.1 Host Initial Pip ID Creation ............................   38
   12.2.2 Host Pip Address Assignment .............................   39
   12.2.3 Pip ID and Domain Name Assignment .......................   39

   13. Pip Control Message Protocol (PCMP) ........................   40

   14. Host Mobility ..............................................   42
   14.1 PCMP Mobile Host message ..................................   43
   14.2 Spoofing Pip IDs ..........................................   44

   15. Public Data Network (PDN) Address Discovery ................   44
   15.1 Notes on Carrying PDN Addresses in NSAPs ..................   46

   16. Evolution with Pip .........................................   46
   16.1 Handling Directive (HD) and Routing Context (RC) Evolution.   49
   16.1.1 Options Evolution .......................................   50
   References .....................................................   51
   Security Considerations ........................................   51
   Author's Address ...............................................   51





























Francis                                                         [Page 3]

RFC 1621               Pip Near-term Architecture               May 1994


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 describes the routing and addressing architecture for
   near-term Pip deployment.  We say near-term only because Pip is
   designed with evolution in mind, so other architectures are expected
   in the future.  This document, however, makes no reference to such
   future architectures (except in that it discusses Pip evolution in
   general).

   This document gives an overall picture of how Pip operates.  It is
   provided primarily as a framework within which to understand the
   total set of documents that comprise Pip.

1.  Pip Architecture Overview

   The Pip near-term architecture is an incremental step from IP.  Like
   IP, near-term Pip is datagram.  Pip runs under TCP and UDP.  DNS is
   used in the same fashion it is now used to distribute name to Pip
   Address (and ID) mappings.  Routing in the near-term Pip architecture
   is hop-by-hop, though it is possible for a host to create a domain-
   level source route (for policy reasons).

   Pip Addresses have more hierarchy than IP, thus improving scaling on
   one hand, but introducing additional addressing complexities, such as
   multiple addresses, on the other.  Pip, however, uses hierarchical
   addresses to advantage by making them provider-based, and using them
   to make policy routing (in this case, provider selection) choices.
   Pip also provides mechanisms for automatically assigning provider
   prefixes to hosts and routers in domains.  This is the main
   difference between the Pip near-term architecture and the IP
   architecture.  (Note that in the remainder of this paper, unless
   otherwise stated, the phrase "Pip architecture" refers to the near-
   term Pip architecture described herein.)

2.  Pip Architecture Characteristics

   The proposed architecture for near-term Pip has the following
   characteristics:

   1.  Provider-rooted hierarchical addresses.

   2.  Automatic domain-wide address prefix assignment.

   3.  Automatic host address and ID assignment.




Francis                                                         [Page 4]

RFC 1621               Pip Near-term Architecture               May 1994


   4.  Exit provider selection.

   5.  Multiple defaults routing (default routing, but to multiple exit
       points).

   6.  Equivalent of IP Class D style addressing for multicast.

   7.  CBT style multicast.

   8.  "Anycast" addressing (route to one of a group, usually the
       nearest).

   9.  Providers support forwarding on policy routes (but initially will
       not provide the support for sources to calculate policy routes).

   10.  Mobile hosts.

   11.  Support for routing across large Public Data Networks (PDN).

   12.  Inter-operation with IP hosts (but, only within an IP-address
        domain where IP addresses are unique).  In particular, an IP
        address can be explicitly carried in a Pip header.

   13.  Operation with existing transport and application binaries
        (though if the application contains IP context, like FTP, it may
        only work within a domain where IP addresses are unique).

   14.  Mechanisms for evolving Pip beyond the near-term architecture.

1.2 Components of the Pip Architecture

   The Pip Architecture consists of the following five systems:

   1.  Host (source and sink of Pip packets)

   2.  Router (forwards Pip packets)

   3.  DNS

   4.  Pip/IP Translator

   5.  Pip Header Server (formats Pip headers)

   The first three systems exist in the IP architecture, and require no
   explanation here.  The fourth system, the Pip/IP Translator, is
   required solely for the purpose of inter-operating with current IP
   systems.  All Pip routers are also Pip/IP translators.




Francis                                                         [Page 5]

RFC 1621               Pip Near-term Architecture               May 1994


   The fifth system, the Pip Header Server, is new.  Its function is to
   format Pip headers on behalf of the source host (though initially
   hosts will be able to do this themselves).  This use of the Pip
   Header Server will increase as policy routing becomes more
   sophisticated (moves beyond near-term Pip Architecture capabilities).

   To handle future evolution, a Pip Header Server can be used to
   "spoon-feed" Pip headers to old hosts that have not been updated to
   understand new uses of Pip.  This way, the probability that the
   internet can evolve without changing all hosts is increased.