rfc1621.txt

RFC 的详细文档！

   must be subject to access control so that excess real-time traffic
   does not swamp a link (to the detriment of other real-time and non-
   real-time traffic alike).

   Given that a consensus solution to real- and non-real-time traffic
   management in the internet does not exist, this version of the Pip
   near-term architecture does not specify any classes of service (and
   related queueing mechanisms).  It is expected that Pip will define
   classes of service (primarily for use in the Handling Directive) as
   solutions become available.



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


8.  Routing on (Hierarchical) Pip Addresses

   Pip forwarding in a single router is done based on one or a small
   number of FTIFs.  What this means with respect to hierarchical Pip
   Addresses is that a Pip router is able to forward a packet based on
   examining only part of the Pip Address--often a single level.

   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, s