rfc1621.txt

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

   One advantage to encoding each level of the Pip Address separately is
   that it makes handling of addresses, for instance address assignment
   or managing multiple addresses, easier.  Another advantage is address
   lookup speed--the entire address does not have to be examined to
   forward a packet (as is necessary, for instance, with traditional
   hierarchical address encoding).  The cost of this, however, is
   additional complexity in keeping track of the active hierarchical
   level in the Pip header.

   Since Pip Addresses allow reuse of numbers at each level of the
   hierarchy, it is necessary for a Pip router to know which level of
   the hierarchy it is acting at when it retrieves an FTIF.  This is
   done in part with a hierarchy level indicator in the Routing Context
   (RC) field.  RC level is numbered from the top of the hierarchy down.
   Therefore, the top of the hierarchy is RC level = 0, the next level
   down is RC level = 1, and so on.

   The RC level alone, however, is not adequate to keep track of the
   appropriate level in all cases.  This is because different parts of
   the hierarchy may have different numbers of levels, and elements of
   the hierarchy (such as a domain or an area) may exist in multiple
   parts of the hierarchy.  Thus, a hierarchy element can be, say, level
   3 under one of its parents and level 2 under another.

   To resolve this ambiguity, the topological hierarchy is superimposed
   with another set of levels--metalevels [11].  A metalevel boundary
   exists wherever a hierarchy element has multiple parents with
   different numbers of levels, or may with reasonable probability have
   multiple parents with different numbers of levels in the future.

   Thus, a metalevel boundary exists between a subscriber network and
   its provider.  (Note that in general the metalevel represents a
   significant administrative boundary between two levels of the
   topological hierarchy.  It is because of this administrative boundary
   that the child is likely to have multiple parents.) Lower metalevels
   may exist, but usually will not.

   The RC, then, contains a level and a metalevel indicator.  The level
   indicates the number of levels from the top of the next higher
   metalevel.  The top of the global hierarchy is metalevel 0, level 0.
   The next level down (for instance, the level that provides a level of



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


   hierarchy within a provider) is metalevel 0, level 1.  The first
   level of hierarchy under a provider is metalevel 1, level 0, and so
   on.

   To determine the RC level and RC metalevel in a transmitted Pip
   packet, a host (or Pip Header Server) must know where the metalevels
   are in its own Pip Addresses.

   The host compares its source Pip Address with the destination Pip
   Address.  The highest Pip Address component that is different between
   the two addresses determines the level and metalevel.  (No levels
   higher than this level need be encoded in the Routing Directive.)

   Neighbor routers are configured to know if there is a level or
   metalevel boundary between them, so that they can modify the RC level
   and RC metalevel in a transmitted packet appropriately.

8.1  Exiting a Private Domain

   The near-term Pip Architecture provides two methods of exit routing,
   that is, routing inter-domain Pip packets from a source host to a
   network service provider of a private domain [12,15].  In the first
   method, called transit-driven exit routing, the source host leaves
   the choice of provider to the routers.  In the second method, called
   host-driven exit routing, the source host explicitly chooses the
   provider.  In either method, it is possible to prevent internal
   routers from having to carry external routing information.  The exit
   routing bit of the RC indicates which type of exit routing is in
   effect.

   With host-driven exit routing, it is possible for the host to choose
   a provider through which the destination cannot be reached.  In this
   case, the host receives the appropriate PCMP Packet Not Delivered
   message, and may either fallback on transit-driven exit routing or
   choose a different provider.

   When using transit-driven exit routing, there are two modes of
   operation.  The first, called destination-oriented, is used when the
   routers internal to a domain have external routing information, and
   the host has only one provider prefix.  The second, called provider-
   oriented, is used when the routers internal to a domain do not have
   any external routing information or when the host has multiple
   provider prefixes.  (With IP, this case is called default routing.
   In the case of IP, however, default routing does not allow an
   intelligent choice of multiple exit points.)

   With provider-oriented exit routing, the host arbitrarily chooses a
   source Pip Address (and therefore, a provider).  (Note that if the



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


   Pip Header Server is tracking inter-domain routing, then it chooses
   the appropriate provider.) If the host chooses the wrong provider,
   then the border router will redirect the host to the correct provider
   with a PCMP Provider Redirect message.

8.2  Intra-domain Networking

   With intra-domain networking (where both source and destination are
   in the private network), there are two scenarios of concern.  In the
   first, the destination address shares a providerPart with the source
   address, and so the destination is known to be intra-domain even
   before a packet is sent.  In the second, the destination address does
   not share a providerPart with the source address, and so the source
   host doesn't know that the destination is reachable intra-domain.
   Note that the first case is the most common, because the private
   top-level number assignment acts as the common prefix even though it
   isn't advertised globally (see section 4.1).

   In the first case, the Pip Addresses in the Routing Directive need
   not contain the providerPart.  Rather, it contains only the address
   part below the metalevel boundary.  (A Pip Address in an FTIF Chain
   always starts at a metalevel boundary).

   For instance, if the source Pip Address is 1.2.3,4.5.6 and the
   destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be
   included for the destination address in the Routing Directive.  (The
   comma "," in the address indicates the metalevel boundary between
   providerPart and subscriberPart.) The metalevel and level are set
   accordingly.

   In the second case, it is desirable to use the Pip Header Server to
   determine if the destination is intra-domain or inter-domain.  The
   Pip Header Server can do this by monitoring intra-domain routing.
   (This is done by having the Pip Header Server run the intra-domain
   routing algorithm, but not advertise any destinations.) Thus, the Pip
   Header Server can determine if the providerPart can be eliminated
   from the address, as described in the last paragraph, or cannot and
   must conform to the rules of exit routing as described in the
   previous section.

   If the Pip Header Server does not monitor intra-domain routing,
   however, then the following actions occur.  In the case of host-
   driven exit routing, the packet will be routed to the stated
   provider, and an external path will be used to reach an internal
   destination.  (The moral here is to not use host-driven exit routing
   unless the Pip Header Server is privy to routing information, both
   internal and external.)




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


   In the case of transit-driven exit routing, the packet sent by the
   host will eventually reach a router that knows that the destination
   is intra-domain.  This router will forward the packet towards the
   destination, and at the same time send a PCMP Reformat Transit Part
   message to the host.  This message tells the host how much of the Pip
   Address is needed to route the packet.

9.  Pip Header Server

   Two new components of the Pip Architecture are the Pip/IP Translator
   and the Pip Header Server.  The Pip/IP Translator is only used for
   transition from IP to Pip, and otherwise would not be necessary.  The
   Pip Header Server, however, is a new architectural component.

   The purpose of the Pip Header Server is to form a Pip Header.  It is
   useful to form the Pip header in a separate box because 1) in the
   future (as policy routing matures, for instance), significant amounts
   of information may be needed to form the Pip header--too much
   information to distribute to all hosts, and 2) it won't be possible
   to evolve all hosts at the same time, so the existence of a separate
   box that can spoon-feed Pip headers to old hosts is necessary.  (It
   is impossible to guarantee that no modification of Pip hosts is
   necessary for any potential evolution, but being able to form the
   header in a server, and hand it to an outdated host, is a large step
   in the right direction.)

   (Note that policy routing architectures commonly if not universally
   require the use of some kind of "route server" for calculating policy
   routes.  The Pip Header Server is, among other things, just this
   server.  Thus, the Pip Header Server does not so much result from the
   fact that Pip itself is more complex than IP or other "IPv7"
   proposals.  Rather, the Pip Header Server reflects the fact that the
   Pip Architecture has more functionality than ROAD architectures
   supported by the simpler proposals.)

   We note that for the near-term architecture hosts themselves will
   by-and-large have the capability of forming Pip headers.  The
   exception to this will be the case where the Pip Header Server wishes
   to monitor inter-domain routing to enhance provider selection.  Thus,
   the Pip Header Server role will be largely limited to evolution (see
   section 16).

9.1  Forming Pip Headers

   Forming a Pip header is more complex than forming an IP header
   because there are many more choices to make.  At a minimum, one of
   multiple Pip Addresses (both source and destination) must be chosen
   [14].  In the near future, it will also be necessary to choose a TOS.



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


   After DNS information about the destination has been received, the
   the following information is available to the Pip header formation
   function.

   1.  From DNS: The destination's providers (either directly connected
       or nearby enough to justify making a policy decision about), and
       the names, types, and access restrictions of those providers.

   2.  From the source host: The application type (and thus, the desired
       service), and the user access restriction classes.

   3.  From local configuration: The source's providers, and the names,
       types, and access restrictions of those providers.

   4.  Optionally from inter-domain routing: The routes chosen by
       inter-domain to all top level providers.  (Note that inter-domain
       routing in the Pip near-term architecture is path-vector.
       Because of this, the Pip Header Server does not obtain enough
       information from inter-domain routing to form a policy route.
       When the technology to do this matures, it can be installed into
       Pip Header Servers.)

       The inter-domain routing information is optional.  If it is used,
       then probably a Pip Header Server is necessary, to limit this
       information to a small number of systems.

   There may also be arbitrary policy information available to the Pip
   header formation function.  This architecture does not specify any
   such information.

   The Pip header formation function then goes through a process of
   forming an ordered list of source/destination Pip Addresses to use.
   The ordering is based on knowledge of the application service
   requirements, the service provided by the source providers, guesses
   or learned information about the service provided by the destination
   providers or by source/destination provider pairs, and the cost of
   using source providers to reach destination providers.  It is assumed
   that the sophistication of forming the ordered list will grow as
   experienced is gained with internet commercialization and real-time
   services.

   The Pip Header formation function then returns the ordered pairs of
   source and destination addresses to the source host in the PHP
   response message, along with an indication of what kind of exit
   routing to use with each pair.  Any additional information, such as
   PDN Address, is also returned.  With this information, the source
   host can now establish communications and properly respond to PCMP
   messages.  Based on information received from PCMP messages,



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


   particularly PCMP Packet Not Delivered messages but also Mobile Host
   messages, the host is able to choose appropriately from the ordered
   list.

   Note that if Pip evolves to the point where the Transit Part of the
   Pip header is no longer compatible with the current Transit Part, and
   the querying host has not been updated to understand the new Transit
   Part, then the PHP response message contains a bit map of the Transit
   Part.  The host puts this bit map into the Transit Part of the
   transmitted Pip header even though it does not understand the
   semantics of the Transit Part.  The Host Version field indicates to
   the Pip Header Server what kinds of transit parts the host can
   understand.

9.2  Pip Header Protocol (PHP)

   The Pip Header Protocol (PHP) is a simple query/response protocol
   used to exchange information between the Pip host and the Pip Header
   Server [6].  In the query, the Pip host includes (among other things)
   the domain name of the destination it wishes to send Pip packets to.
   (Thus, the PHP query serves as a substit