rfc1621.txt

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

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


      bits       meaning
      ----       -------
      0,1        Anycast Address (= 11)
      2,3        level
      4,5        metalevel
      6          exit routing type
      7          anycast active
      8,9        scoping


   With anycast routing, the packet is unicast, but to the nearest of a
   group of destinations.  This type of routing is used by Pip for
   autoconfiguration.  Other applications, such as discovery protocols,
   may also use anycast routing.

   Like CBT, Pip anycast has two phases of operation, in this case the
   unicast phase and the anycast phase.  The unicast phase is for the
   purpose of getting the packet into a certain vicinity.  The anycast
   phase is to forward the packet to the nearest of a group of
   destinations in that vicinity.

   Thus, the RC has both unicast and anycast information in it.  During
   the unicast phase, the anycast active bit is set to 0, and the packet
   is forwarded according to the rules of Pip Addressing.  The scoping
   bits are ignored.

   The switch from the unicast phase to the anycast phase is triggered
   by the presence of an FTIF of value 1 in the FTIF Chain.  When this
   FTIF is reached, the anycast active bit is set to 1, the scoping bits
   take effect, and bits 2 through 6 are ignored.  When in the anycast
   phase, forwarding is based on the Dest ID field.

5.  Pip IDs

   The Pip ID is 64-bits in length [4].

   The basic role of the Pip ID is to identify the source and
   destination host of a Pip Packet.  (The other role of the Pip ID is
   for allowing a router to find the destination host on the destination
   subnetwork.)

   This having been said, it is possible for the Pip ID to ultimately
   identify something in addition to the host.  For instance, the Pip ID
   could identify a user or a process.  For this to work, however, the
   Pip ID has to be bound to the host, so that as far as the Pip layer
   is concerned, the ID is that of the host.  Any additional use of the
   Pip ID is outside the scope of this Pip architecture.




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


   The Pip ID is treated as flat.  When a host receives a Pip packet, it
   compares the destination Pip ID in the Pip header with its' own.  If
   there is a complete match, then the packet has reached the correct
   destination, and is sent to the higher layer protocol.  If there is
   not a complete match, then the packet is discarded, and a PCMP
   Invalid Address packet is returned to the originator of the packet
   [7].

   It is something of an open issue as to whether or not Pip IDs should
   contain significant organizational hierarchy information.  Such
   information could be used for inverse DNS lookups and allowing a Pip
   packet to be associated with an organization.  (Note that the use of
   the Pip ID alone for this purpose can be easily spoofed.  By cross
   checking the Pip ID with the Pip Address prefix, spoofing is harder-
   -as hard as it is with IP--but still easy.  Section 14.2 discusses
   methods for making spoofing harder still, without requiring
   encryption.)

   However, relying on organizational information in the Pip header
   generally complicates ID assignment.  This complication has several
   ramifications.  It makes host autoconfiguration of hosts harder,
   because hosts then have to obtain an assignment from some database
   somewhere (versus creating one locally from an IEEE 802 address, for
   instance).  It means that a host has to get a new assignment if it
   changes organizations.  It is not clear what the ramifications of
   this might be in the case of a mobile host moving through different
   organizations.

   Because of these difficulties, the use of flat Pip IDs is currently
   favored.

   Blocks of Pip ID numbers have been reserved for existing numbering
   spaces, such as IP, IEEE 802, and E.164.  Pip ID numbers have been
   assigned for such special purposes such as "any host", "any router",
   "all hosts on a subnetwork", "all routers on a subnetwork", and so
   on.  Finally, 32-bit blocks of Pip ID numbers have been reserved for
   each country, according to ISO 3166 country code assignments.

6.  Use of DNS

   The Pip near-term architecture uses DNS in roughly the same style
   that it is currently used.  In particular, the Pip architecture
   maintains the two fundamental DNS characteristics of 1) information
   stored in DNS does not change often, and 2) the information returned
   by DNS is independent of who requested it.

   While the fundamental use of DNS remains roughly the same, Pip's use
   of DNS differs from IP's use by degrees.  First, Pip relies on DNS to



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


   hold more types of information than IP [1].  Second, Pip Addresses in
   DNS are expected to change more often than IP addresses, due to
   reassignment of Pip Address prefixes (the providerPart).  To still
   allow aggressive caching of DNS records in the face of more quickly
   changing addressing, Pip has a mechanism of indicating to hosts when
   an address is no longer assigned.  This triggers an authoritative
   query, which overrides DNS caches.  The mechanism consists of PCMP
   Packet Not Delivered messages that indicate explicitly that the Pip
   Address is invalid.

   In what follows, we first discuss the information contained in DNS,
   and then discuss authoritative queries.

6.1  Information Held by DNS

   The information contained in DNS for the Pip architecture is:

   1.  The Pip ID.

   2.  Multiple Pip Addresses

   3.  The destination's mobile host address servers.

   4.  The Public Data Network (PDN) addresses through which the
       destination can be reached.

   5.  The Pip/IP Translators through which the destination (if the
       destination is IP-only) can be reached.

   6.  Information about the providers represented by the destination's
       Pip addresses.  This information includes provider name, the type
       of provider network (such as SMDS, ATM, or SIP), and access
       restrictions on the provider's network.

   The Pip ID and Addresses are the basic units of information required
   for carriage of a Pip packet.

   The mobile host address server tells where to send queries for the
   current address of a mobile Pip host. Note that usually the current
   address of the mobile host is conveyed by the mobile host itself,
   thus a mobile host server query is not usually required.

   The PDN address is used by the entry router of a PDN to learn the PDN
   address of the next hop router.  The entry router obtains the PDN
   address via an option in the Pip packet.  If there are multiple PDNs
   associated with a given Pip Address, then there can be multiple PDN
   addresses carried in the option.  Note that the option is not sent on
   every packet, and that only the PDN entry router need examine the



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


   option.

   The Pip/IP translator information is used to know how to translate an
   IP address into a Pip Address so that the packet can be carried
   across the Pip infrastructure.  If the originating host is IP, then
   the first IP/Pip translator reached by the IP packet must query DNS
   for this information.

   The information about the destination's providers is used to help the
   "source" (either the source host or a Pip Header Server near the
   source host) format an appropriate Pip header with regards to
   choosing a Pip Address [14].  The choice of one of multiple Pip
   Addresses is essentially a policy routing choice.

   More detailed descriptions of the use of the information carried in
   DNS is contained in the relevant sections.

6.2 Authoritative Queries in DNS

   In general, Pip treats addresses as more dynamic entities than does
   IP.  One example of this is how Pip Address prefixes change when a
   subscriber network attaches to a new provider.  Pip also carries more
   information in DNS, any of which can change for various reasons.
   Thus, the information in DNS is more dynamic with Pip than with IP.

   Because of the increased reliance on DNS, there is a danger of
   increasing the load on DNS.  This would be particularly true if the
   means of increasing DNS' dynamicity is by shortening the cache
   holding time by decreasing the DNS Time-to-Live (TTL).  To counteract
   this trend, Pip provides explicit network layer (Pip layer) feedback
   on the correctness of address information.  This allows Pip hosts to
   selectively over-ride cached DNS information by making an
   authoritative query.  Through this mechanism, we actually hope to
   increase the cache holding time of DNS, thus improving DNS' scaling
   characteristics overall.

   The network layer feedback is in the form of a type of PCMP Packet
   Not Delivered (PDN) message that indicates that the address used is
   known to be out-of-date.  Routers can be configured with this
   information, or it can be provided through the routing algorithm
   (when an address is decommissioned, the routing algorithm can
   indicate that this is the reason that it has become unreachable, as
   opposed to becoming "temporarily" unreachable through equipment
   failure).

   Pip hosts consider destination addresses to be in one of four states:





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


   1.  Unknown, but assumed to be valid.

   2.  Reachable (and therefore valid).

   3.  Unreachable and known to be invalid.

   4.  Unreachable, but weakly assumed to be valid.

   The first state exists before a host has attempted communication with
   another host.  In this state, the host queries DNS as normal (that
   is, does not make an authoritative query).

   The second state is reached when a host has successfully communicated
   with another host.  Once a host has reached this state, it can stay
   in it for an arbitrarily long time, including after the DNS TTL has
   expired.  When in this state, there is no need to query DNS.

   A host enters the third state after a failed attempt at communicating
   with another host where the PCMP PND message indicates explicitly
   that the address is known to be invalid.  In this case, the host
   makes an authoritative query to DNS whether or not the TTL has
   expired.  It is this case that allows lengthy caching of DNS
   information while still allowing addresses to be reassigned
   frequently.

   A host enters the fourth state after a failed attempt at
   communicating with another host, but where the address is not
   explicitly known to be invalid.  In this state, the host weakly
   assumes that the address of the destination is still valid, and so
   can requery DNS with a normal (non-authoritative) query.

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

   One year ago it probably would have been adequate to define a handful
   (4 or 5) of priority levels to drive a simple priority FIFO queue.
   With the advent of real-time services over the Internet, however,
   this is no longer sufficient.  Real-time traffic cannot be handled on
   the same footing as non-real-time.  In particular, real-time traffic
   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.