rfc1621.txt

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

   where both the providerPart and subscriberPart can have multiple
   layers of hierarchy internally.

   A subscriber may be attached to multiple providers.  In this case, a
   host can end up with multiple Pip Addresses by virtue of having
   multiple providerParts:

         providerPart1,subscriberPart
         providerPart2,subscriberPart
         providerPart3,subscriberPart

   This applies to the case where the subscriber network spans many
   different provider areas, for instance, a global corporate network.
   In this case, some hosts in the global corporate network will have
   certain providerParts, and other hosts will have others.  The
   subscriberPart should be assigned such that routing can successfully
   take place without a providerPart in the destination Pip Address of
   the Pip Routing Directive (see section 8.2).




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


   Note that, while there are three providerParts shown, there is only
   one subscriberPart.  Internal subscriber numbering should be
   independent of the providerPart.  Indeed, with the Pip architecture,
   it is possible to address internal packets without including any of
   the providerPart of the address.

   Top-level Pip numbers can be assigned to subscriber networks as well
   as to providers.

         privatePart,subscriberPart

   In this case, however, the top-level number (privatePart) would not
   be advertised globally.  The purpose of such an assignment is to give
   a private network "ownership" of a globally unique Pip Address space.
   Note that the privatePart is assigned as an extended FTIF (that is,
   from numbers greater than 2^15).  Because the privatePart is not
   advertised globally, and because internal packets do not need the
   prefix (above the subscriberPart), the privatePart actually never
   appears in a Pip packet header.

   Pip Addresses can be prepended with a route fragment.  That is, one
   or more Pip numbers that are all at the top of the hierarchy.

         longDistanceProvider.localAccessProvider.subscriber
             (top-level)          (top-level)     (next level)

   This is useful, for instance, when the subscriber's directly attached
   provider is a "local access" provider, and is not advertised
   globally.  In this case, the "long distance" provider is prepended to
   the address even though the local access provider number is enough to
   provide global uniqueness.

   Note that no coordination is required between the long distance and
   local access providers to form this address.  The subscriber with a
   prefix assigned to it by the local access provider can autonomously
   form and use this address.  It is only necessary that the long
   distance provider know how to route to the local access provider.

4.1.1  Assignment of (Hierarchical) Pip Addresses

   Administratively, Pip Addresses are assigned as follows [3].  There
   is a root Pip Address assignment authority.  Likely choices for this
   are IANA or ISOC.  The root authority assigns top-level Pip Address
   numbers.  (A "Pip Address number" is the number at a single level of
   the Pip Address hierarchy.  A Pip Address prefix is a series of
   contiguous Pip Address numbers, starting at the top level but not
   including the entire Pip Address.  Thus, the top-level prefix is the
   same thing as the top-level number.)



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


   Though by-and-large, and most importantly, top-level assignments are
   made to providers, each country is given an assignment, each existing
   address space (such as E.164, X.121, IP, etc.) is given an
   assignment, and private networks can be given assignments.  Thus,
   existing addresses can be grandfathered in.  Even if the top-level
   Pip address number is an administrative rather than topological
   assignment, the routing algorithm still advertises providers at the
   top (provider) level of routing.  That is, routing will advertise
   enough levels of hierarchy that providers know how to route to each
   other.

   There must be some means of validating top-level number requests from
   providers (basically, those numbers less than 2^15).  That is, top-
   level assignments must be made only to true providers.  While
   designing the best way to do this is outside the scope of this
   document, it seems off hand that a reasonable approach is to charge
   for the top-level prefixes.  The charge should be enough to
   discourage non-serious requests for prefixes, but not so much that it
   becomes an inhibitor to entry in the market.  The charge might
   include a yearly "rent", and top-level prefixes could be reclaimed
   when they are no longer used by the provider.  Any profit made from
   this activity could be used to support the overall role of number
   assignment.  Since roughly 32,000 top-level assignments can be made
   before having to increase the FTIF size in the Pip header from 16
   bits to 32 bits, it is envisioned that top-level prefixes will not be
   viewed as a scarce resource.

   After a provider obtains a top-level prefix, it becomes an assignment
   authority with respect to that particular prefix.  The provider has
   complete control over assignments at the next level down (the level
   below the top-level).  The provider may either assign top-level minus
   one prefixes to subscribers, or preferably use that level to provide
   hierarchy within the provider's network (for instance, in the case
   where the provider has so many subscribers that keeping routing
   information on all of them creates a scaling problem).  It is
   envisioned that the subscriber will have complete control over number
   assignments made at levels below that of the prefix assigned it by
   the provider.

   Assigning top level prefixes directly to providers leaves the number
   of top-level assignments open-ended, resulting in the possibility of
   scaling problems at the top level.  While it is expected that the
   number of providers will remain relatively small (say less than 10000
   globally), this can't be guaranteed.  If there are more providers
   than top-level routing can handle, it is likely that many of these
   providers will be "local access" providers--providers whose role is
   to give a subscriber access to multiple "long-distance" providers.
   In this case, the local access providers need not appear at the top



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


   level of routing, thus mitigating the scaling problem at that level.

   In the worst case, if there are too many top-level "long-distance"
   providers for top-level routing to handle, a layer of hierarchy above
   the top-level can be created.  This layer should probably conform to
   some policy criteria (as opposed to a geographical criteria).  For
   instance, backbones with similar access restrictions or type-of-
   service can be hierarchically clustered.  Clustering according to
   policy criteria rather than geographical allows the choice of address
   to remain an effective policy routing mechanism.  Of course, adding a
   layer of hierarchy to the top requires that all systems, over time,
   obtain a new providerPart prefix.  Since Pip has automatic prefix
   assignment, and since DNS hides addresses from users, this is not a
   debilitating problem.

4.1.2  Host Addressing

   Hosts can have multiple Pip Addresses.  Since Pip Addresses are
   topologically significant, a host has multiple Pip Addresses because
   it exists in multiple places topologically.  For instance, a host can
   have multiple Pip addresses because it can be reached via multiple
   providers, or because it has multiple physical interfaces.  The
   address used to reach the host influences the path to the host.

   Locally, Pip Addressing is similar to IP Addressing.  That is, Pip
   prefixes are assigned to subnetworks (where the term subnetwork here
   is meant in the OSI sense.  That is, it denotes a network operating
   at a lower layer than the Pip layer, for instance, a LAN).  Thus, it
   is not necessary to advertise individual hosts in routing updates--
   routers only need to advertise and store routes to subnetworks.

   Unlike IP, however, a single subnetwork can have multiple prefixes.
   (Strictly speaking, in IP a single subnetwork can have multiple
   prefixes, but a host may not be able to recognize that it can reach
   another host on the same subnetwork but with a different prefix
   without going through a router.)

   There are two styles of local Pip Addressing--one where the Pip
   Address denotes the host, and another where the Pip Address denotes
   only the destination subnetwork.  The latter style is called ID-
   tailed Pip Addressing.  With ID-tailed Pip Addresses, the Pip ID is
   used by the last router to forward the packet to the host.  It is
   expected that ID-tailed Pip Addressing is the most common, because it
   greatly eases address administration.

   (Note that the Pip Routing Directive can be used to route a Pip
   packet internal to a host.  For instance, the RD can be used to
   direct a packet to a device in a host, or even a certain memory



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


   location.  The use of the RD for this purpose is not part of this
   near-term Pip architecture.  We note, however, that this use of the
   RD could be locally done without effecting any other Pip systems.)

   When a router receives a Pip packet and determines that the packet is
   destined for a host on one of its' attached subnetworks (by examining
   the appropriate FTIF), it then examines the destination Pip ID (which
   is in a fixed position) and forwards based on that.  If it does not
   know the subnetwork address of the host, then it ARPs, using the Pip
   ID as the "address" in the ARP query.

4.2  CBT Style Multicast Addresses

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10,
   the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast.
   The remainder of the bits are defined as follows:


      bits       meaning
      ----       -------
      0,1        CBT Multicast (= 10)
      2,3        level
      4,5        metalevel
      6          exit routing type
      7          on-tree bit
      8,9        scoping


   With CBT (Core-based Tree) multicast, there is a single multicast
   tree connecting the members (recipients) of the multicast group (as
   opposed to Class-D style multicast, where there is a tree per
   source).  The tree emanates from a single "core" router.  To transmit
   to the group, a packet is routed to the core using unicast routing.
   Once the packet reaches a router on the tree, it is multicast using a
   group ID.

   Thus, the FTIF Chain for CBT multicast contains the (Unicast)
   Hierarchical Pip Address of the core router. The Dest ID field
   contains the group ID.

   A Pip CBT packet, then, has two phases of forwarding, a unicast phase
   and a multicast phase.  The "on-tree" bit of the RC indicates which
   phase the packet is in.  While in the unicast phase, the on-tree bit
   is set to 0, and the packet is forwarded similarly to Pip Addresses.
   During this phase, the scoping bits are ignored.






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


   Once the packet reaches the multicast tree, it switches to multicast
   routing by changing the on-tree bit to 1 and using the Dest ID group
   address for forwarding.  During this phase, bits 2-6 are ignored.

4.3  Class D Style Multicast Addresses

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01,
   the FTIF and Dest ID indicate Class D style multicast.  The remainder
   of the RC is defined as:


      bits       meaning
      ----       -------
      0,1        Class D Style Multicast (= 01)
      2-5        Scoping


   By "class D" style multicast, we mean multicast using the algorithms
   developed for use with Class D addresses in IP (class D addresses are
   not used per se).  This style of routing uses both source and
   destination information to route the packet (source host address and
   destination multicast group).

   For Pip, the FTIF Chain holds the source Pip Address, in order of
   most significant hierarchy level first.  The reason for putting the
   source Pip Address rather than the Source ID in the FTIF Chain is
   that use of the source Pip Address allows the multicast routing to
   take advantage of the hierarchical source address, as is being done
   with IP.  The Dest ID field holds the multicast group.  The Routing
   Context indicates Class-D style multicast.  All routers must first
   look at the FTIF Chain and Dest ID field to route the packet on the
   tree.

   Bits 2 through 5 of the RC are the scoping bits.

4.4  Anycast Addressing

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11,
   the FTIF and Dest ID indicate Anycast addressing.  The remainder of
   the RC is defined as: