rfc1621.txt

RFC 的详细文档！

   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.

2.  A Simple Example

   A typical Pip "exchange" is as follows: An application initiates an
   exchange with another host as identified by a domain name.  A request
   for one or more Pip Headers, containing the domain name of the
   destination host, goes to the Pip Header Server.  The Pip Header
   Server generates a DNS request, and receive back a Pip ID, multiple
   Pip Addresses, and possibly other information such as a mobile host
   server or a PDN address.  Given this information, plus information
   about the source host (its Pip Addresses, for instance), plus
   optionally policy information, plus optionally topology information,
   the Pip Header Server formats an ordered list of valid Pip headers
   and give these to the host.  (Note that if the Pip Header Server is
   co-resident with the host, as will be common initially, the host
   behavior is similar to that of an IP host in that a DNS request comes
   from the host, and the host forms a Pip header based on the answer
   from DNS.)

   The source host then begins to transmit Pip packets to the
   destination host.  If the destination host is an IP host, then the
   Pip packet is translated into an IP packet along the way.  Assuming
   that the destination host is a Pip host, however, the destination
   host uses the destination Pip ID alone to determine if the packet is
   destined for it.  The destination host generates a return Pip header
   based either on information in the received Pip header, or the
   destination host uses the Pip ID of the source host to query the Pip
   Header Server/DNS itself.  The latter case involves more overhead,
   but allows a more informed decision about how to return packets to
   the originating host.

   If either host is mobile, and moves to a new location, thus getting a
   new Pip Address, it informs the other host of its new address
   directly.  Since host identification is based on the Pip ID and not
   the Pip Address, this doesn't cause transport level to fail.  If both
   hosts are mobile and receive new Pip Addresses at the same time (and
   thus cannot exchange packets at all), then they can query each
   other's respective mobile host servers (learned from DNS).  Note that



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


   keeping track of host mobility is completely confined to hosts.
   Routers never get involved in tracking mobile hosts (though naturally
   they are involved in host discovery and automatic host address
   assignment).

3.  Pip Overview

   Here, a brief overview of the Pip protocol is given.  The reader is
   encouraged to read [2] for a complete description.

   The Pip header is divided into three parts:

      Initial Part
      Transit Part
      Options Part

   The Initial Part contains the following fields:

      Version Number
      Options Offset, OP Contents, Options Present (OP)
      Packet SubID
      Protocol
      Dest ID
      Source ID
      Payload Length
      Host Version
      Payload Offset
      Hop Count

   All of the fields in the Initial Part are of fixed length.  The
   Initial Part is 8 32-bit words in length.

   The Version Number places Pip as a subsequent version of IP.  The
   Options Offset, OP Contents, and Options Present (OP) fields tell how
   to process the options.  The Options Offset tells where the options
   are The OP tells which of up to 8 options are in the options part, so
   that the Pip system can efficiently ignore options that don't pertain
   to it.  The OP Contents is like a version number for the OP field.
   It allows for different sets of the (up to 8) options.

   The Packet SubID is used to relate a received PCMP message to a
   previously sent Pip packet.  This is necessary because, since routers
   in Pip can tag packets, the packet returned to a host in a PCMP
   message may not be the same as the packet sent.  The Payload Length
   and Protocol take the place of IP's Total Length and Protocol fields
   respectively.  The Dest ID identifies the destination host, and is
   not used for routing, except for where the final router on a LAN uses
   ARP to find the physical address of the host identified by the dest



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


   ID.  The Source ID identifies the source of the packet.  The Host
   Version tells what control algorithms the host has implemented, so
   that routers can respond to hosts appropriately.  This is an
   evolution mechanism.  The Hop Count is similar to IP's Time-to-Live.

   The Transit Part contains the following fields:

      Transit Part Offset
      HD Contents
      Handling Directive (HD)
      Active FTIF
      RC Contents
      Routing Context (RC)
      FTIF Chain (FTIF = Forwarding Table Index Field)

   Except for the FTIF Chain, which can have a variable number of 16-bit
   FTIF fields, the fields in the Transit Part are of fixed length, and
   are three 32-bit words in length.

   The Transit Part Offset gives the length of the Transit Part.  This
   is used to determine the location of the subsequent Transit Part (in
   the case of Transit Part encapsulation).

   The Handling Directive (HD) is a set of subfields, each of which
   indicates a specific handling action that must be executed on the
   packet.  Handling directives have no influence on routing.  The HD
   Contents field indicates what subfields are in the Handling
   Directive.  This allows the definition of the set of handling
   directives to evolve over time.  Example handling directives are
   queueing priority, congestion experienced bit, drop priority, and so
   on.

   The remaining fields comprise the Routing Directive.  This is where
   the routing decision gets made.  The basic algorithm is that the
   router uses the Routing Context to choose one of multiple forwarding
   tables.  The Active FTIF indicates which of the FTIFs to retrieve,
   which is then used as an index into the forwarding table, which
   either instructs the router to look at the next FTIF, or returns the
   forwarding information.

   Examples of Routing Context uses are; to distinguish address families
   (multicast vs. unicast), to indicate which level of the hierarchy a
   packet is being routed at, and to indicate a Type of Service.  In the
   near-term architecture, the FTIF Chain is used to carry source and
   destination hierarchical unicast addresses, policy route fragments,
   multicast addresses (all-of-group), and anycast (one-of-group)
   addresses.  Like the OP Contents and HD Contents fields, the RC
   Contents field indicates what subfields are in the Routing Context.



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


   This allows the definition of the Routing Context to evolve over
   time.

   The Options Part contains the options.  The options are preceded by
   an array of 8 fields that gives the offset of each of up to 8
   options.  Thus, a particular option can be found without a serial
   search of the list of options.

4.  Pip Addressing

   Addressing is the core of any internet architecture.  Pip Addresses
   are carried in the Routing Directive (RD) of the Pip header (except
   for the Pip ID, which in certain circumstances functions as part of
   the Pip Address).  Pip Addresses are used only for routing packets.
   They do not identify the source and destination of a Pip packet.  The
   Pip ID does this.  Here we describe and justify the Pip Addressing
   types.

   There are four Pip Address types [11].  The hierarchical Pip Address
   (referred to simply as the Pip Address) is used for scalable unicast
   and for the unicast part of a CBT-style multicast and anycast.  The
   multicast part of a CBT-style multicast is the second Pip address
   type.  The third Pip address type is class-D style multicast.  The
   fourth type of Pip address is the so-called "anycast" address.  This
   address causes the packet to be forwarded to one of a class of
   destinations (such as, to the nearest DNS server).

   Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is,
   for the near-term Pip architecture) indicate which of four address
   families the FTIFs and Dest ID apply to.  The values are:

      Value      Address Family
      -----      --------------
       00        Hierarchical Unicast Pip Address
       01        Class D Style Multicast Address
       10        CBT Style Multicast Address
       11        Anycast Pip Address

   The remaining bits are defined differently for different address
   families, and are defined in the following sections.

4.1  Hierarchical Pip Addressing

   The primary purpose of a hierarchical address is to allow better
   scaling of routing information, though Pip also uses the "path"
   information latent in hierarchical addresses for making provider
   selection (policy routing) decisions.




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


   The Pip Header encodes addresses as a series of separate numbers, one
   number for each level of hierarchy.  This can be contrasted to
   traditional packet encodings of addresses, which places the entire
   address into one field.  Because of Pip's encoding, it is not
   necessary to specify a format for a Pip Address as it is with
   traditional addresses (for instance, the SIP address is formatted
   such that the first so-many bits are the country/metro code, the next
   so-many bits are the site/subscriber, and so on).  Pip's encoding
   also eliminates the "cornering in" effect of running out of space in
   one part of the hierarchy even though there is plenty of room in
   another.  No "field sizing" decisions need be made at all with Pip
   Addresses.  This makes address assignment easier and more flexible
   than with traditional addresses.

   Pip Addresses are carried in DNS as a series of numbers, usually with
   each number representing a layer of the hierarchy [1], but optionally
   with the initial number(s) representing a "route fragment" (the tail
   end of a policy route--a source route whose elements are providers).
   The route fragments would be used, for instance, when the destination
   network's directly attached (local access) provider is only giving
   access to other (long distance) providers, but the important
   provider-selection policy decision has to do the long distance
   providers.

   The RC for (hierarchical) Pip Addresses is defined as:

      bits       meaning
      ----       -------
      0,1        Pip Address (= 00)
      2,3        level
      4,5        metalevel
      6          exit routing type

   The level and metalevel subfields are used to indicate what level of
   the hierarchy the packet is currently at (see section 8).  The exit
   routing type subfield is used to indicate whether host-driven (hosts
   decide exit provider) or router-driven (routers decide exit provider)
   exit routing is in effect (see section 8.1).

   Each FTIF in the FTIF Chain is 16 bits in length.  The low-order part
   of each FTIF in a (hierarchical unicast) Pip Address indicates the
   relationship of the FTIF with the next FTIF.  The three relators are
   Vertical, Horizontal, and Extension.  The Vertical and Horizontal
   relators indicate if the subsequent FTIF is hierarchically above or
   below (Vertical) or hierarchically unrelated (Horizontal).  The
   Extension relator is used to encode FTIF values longer than 16 bits.





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


   FTIF values 0 - 31 are reserved for special purposes.  That is, they
   cannot be assigned to normal hierarchical elements.  FTIF value 1 is
   defined as a flag to indicate a switch from the unicast phase of
   packet forwarding to the anycast phase of packet forwarding.

   Note that Pip Addresses do not need to be seen by protocol layers
   above Pip (though layers above Pip can provide a Pip Address if
   desired).  Transport and above use the Pip ID to identify the source
   and destination of a Pip packet.  The Pip layer is able to map the
   Pip IDs (and other information received from the layer above, such as
   QOS) into Pip Addresses.

   The Pip ID can serve as the lowest level of a Pip Address.  While
   this "bends the principal" of separating Pip Addressing from Pip
   Identification, it greatly simplifies dynamic host address
   assignment.  The Pip ID also serves as a multicast ID.  Unless