rfc2769.txt

<VC++网络游戏建摸与实现>源代码

   In this section, we first describe how a repository may encapsulate
   the submitted text of a transaction.  We then describe the protocol
   for flooding transactions or polling for transactions, and the
   database snapshot contents and format.

7.3  Redistribution Protocol Description

   The originating repository must first authenticate a submitted
   transaction using methods described in [3].






Villamizar, et al.          Standards Track                    [Page 16]

RFC 2769           Routing Policy System Replication       February 2000


   Before redistributing a transaction, the originating repository must
   encapsulate the submitted text of the transaction with several meta-
   objects, which are described below.

   The originating repository must prepend the submitted text with
   exactly one "transaction-label" meta-object.  This meta-object
   contains the following attributes:

   transaction-label  This attribute is mandatory and single.  The value
      of this attribute conforms to the syntax of an RPSL word, and
      represents a globally unique identifier for the database to which
      this transaction is added.

   sequence  This attribute is mandatory and single.  The value of this
      attribute is an RPSL integer specifying the sequence number
      assigned by the originating repository to the transaction.
      Successive transactions distributed by the same originating
      repository have successive sequence numbers.  The first
      transaction originated by a registry is assigned a sequence number
      1.  Each repository must use sequence numbers drawn from a range
      at least as large as 64 bit unsigned integers.

   timestamp  This attribute is mandatory and single-valued.  This
      attribute specifies the time at which the originating repository
      encapsulates the submitted text.  The format of this attribute is
      "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four
      digit year, "MM" represents the month, "DD" the date, "hh" the
      hour, "mm" the minutes, "ss" the seconds of the timestamp, and
      "xx" and "yy" represents the hours and minutes respectively that
      that timestamp is ahead or behind UTC.

   integrity  This attribute is optional and single-valued.  It may have
      the values "legacy", "no-auth", "auth-failed", or "authorized".
      If absent, the integrity is considered to be "authorized".

   The originating repository may append to the submitted text one or
   more "auth-dependency" meta-objects.  These meta-objects are used to
   indicate which other repositories' objects were used by the
   originating registry to authenticate the submitted text.  The "auth-
   dependency" meta-objects should be ordered from the most preferred
   repository to the least preferred repository.  This order is used by
   a remote repository to tie break between the multiple registrations
   of an object with the same level of integrity.  The "auth-dependency"
   meta-object contains the following attributes:

   auth-dependency  This attribute mandatory and single-valued.  It
      equals a repository name from which an object is used to
      authorize/authenticate this transaction.



Villamizar, et al.          Standards Track                    [Page 17]

RFC 2769           Routing Policy System Replication       February 2000


   sequence  This attribute mandatory and single-valued.  It equals the
      transaction sequence number of the dependent repository known at
      the originating repository at the time of processing this
      transaction.

   timestamp  This attribute mandatory and single-valued.  It equals the
      timestamp of the dependent repository known at the originating
      repository at the time of processing this transaction.

   If the originating repository needs to modify submitted objects in a
   way that the remote repositories can not re-create, it can append an
   "override-objects" meta-object followed by the modified versions of
   these objects.  An example modification can be auto assignment of NIC
   handles.  The "override-objects" meta-object contains the following
   attributes:

   override-objects  A free text remark.

   Other repositories may or may not honor override requests, or limit
   the kinds of overrides they allow.

   Following this, the originating repository must append exactly one
   "repository-signature" meta-object.  The "repository-signature"
   meta-object contains the following attributes:

   repository-signature  This attribute is mandatory and single-valued.
      It contains the name of the repository.

   integrity  This attribute is optional and single-valued.  It may have
      the values "legacy", "no-auth", "auth-failed", or "authorized".
      If absent, the value is same as the value in the transaction-
      label.  If a different value is used, the value here takes
      precedence.

   signature  This attribute is optional and single-valued.  This
      attribute, a block of free text, contains the repository's
      signature using the key in the repository-cert attribute of the
      repository object.  When the authentication method is a
      cryptographic hash (as in PGP-based authentication), the signature
      must include all text upto (but not including) this attribute.
      That is, the "repository-signature" and "integrity" attributes of
      this object are included.  This attribute is optional since
      cryptographic authentication may not be available everywhere.
      However, its use where it is available is highly recommended.

   A repository must reject a redistributed transaction that does not
   include any "repository-signature" meta-object.




Villamizar, et al.          Standards Track                    [Page 18]

RFC 2769           Routing Policy System Replication       February 2000


   The transaction-label, the submitted text, the dependency objects,
   the override-objects, the overridden objects, and the repository's
   signature together constitute what we call the "redistributed text".

   In preparation for redistributing the transaction to other
   repositories, the originating repository must perform the following
   protocol encapsulation.  This protocol encapsulation may involve
   transforming the redistributed text according to one of the
   "transfer-method"s described below.

   The transformed redistributed text is first prepended with exactly
   one "transaction-begin" meta-object.  One newline character separates
   this meta-object from the redistributed text.  This meta-object has
   the following attributes:

   transaction-begin  This attribute is mandatory and single.  The value
      of this attribute is the length, in bytes, of the transformed
      redistributed text.

   transfer-method  This attribute is optional and single-valued.  Its
      value is either "gzip", or "plain".  The value of the attribute
      describes the kind of text encoding that the repository has
      performed on the redistributed text.  If this attribute is not
      specified, its value is assumed to be "plain".  An implementation
      must be capable of encoding and decoding both of these types.

   The "transaction-begin" meta-object and the transformed redistributed
   text constitute what we call the "transmitted text".  The originating
   repository may distribute the transmitted text to one or more peer
   repositories.

   When a repository receives the transmitted text of a transaction, it
   must perform the following steps.  After performing the following
   steps, a transaction may be marked successful or failed.

   1. It must decapsulate the "transaction-begin" meta-object, then
      decode the original redistributed text according to the value of
      the transfer-method attribute specified in the "transaction-begin"
      meta-object.

   2. It should then extract the "transaction-label" meta-object from
      the transmitted text.  If this transaction has already been
      processed, or is currently being held, the repository must
      silently discard this incarnation of the same transaction.

   3. It should verify that the signature of the originating repository
      matches the first "repository-signature" meta-object in the
      redistributed text following the "auth-dependency" meta-objects.



Villamizar, et al.          Standards Track                    [Page 19]

RFC 2769           Routing Policy System Replication       February 2000


   4. If not all previous (i.e., those with a lower sequence number)
      transactions from the same repository have been received or
      completely processed, the repository must "hold" this transaction.

   5. It may check whether any subsequent "repository-signature" meta-
      objects were appended by a trusted repository.  If so, this
      indicates that the trusted repository verified the transaction's
      integrity and marked its conclusion in the integrity attribute of
      this object.  The repository may verify the trusted repositories
      signature and also mark the transaction with the same integrity,
      and skip the remaining steps.

   6. It should verify the syntactic correctness of the transaction.  An
      implementation may allow configurable levels of syntactic
      conformance with RPSL [1].  This enables RPSL extensions to be
      incrementally deployed in the distributed registry scheme.

   7. The repository must authorize and authenticate this transaction.
      To do this, it may need to reference objects and transactions from
      other repositories.  If these objects are not available, the
      repository must "hold" this transaction as described in Section
      7.6, until it can be authorized and authenticated later.  In order
      to verify authorization/authentication of this transaction, the
      repository must not use an object from a repository not mentioned
      in an "auth-dependency" meta-object.  The repository should also
      only use the latest objects (by rolling back to earlier versions
      if necessary) which are within the transaction sequence numbers of
      the "auth-dependency" meta-objects.

   A non-originating repository must redistribute a failed transaction
   in order not to cause a gap in the sequence.  (If the transaction was
   to fail at the originating registry, it would simply not be assigned
   a sequence number).

   To the redistributed text of a transaction, a repository may append
   another "repository-signature" meta-object.  This indicates that the
   repository has verified the transaction's integrity and marked it in
   the "integrity" attribute of this object.  The signature covers the
   new redistributed text from (and including) the transaction-label
   object to this object's signature attribute (including the
   "repository-signature" and "integrity" attributes of this object, but
   excluding the "signature" attribute).  The original redistributed
   text, together with the new "repository-signature" meta-object
   constitutes the modified redistributed text.

   To redistribute a successful or failed transaction, the repository
   must encapsulate the (original or modified) redistributed text with a
   "transaction-begin" object.  This step is essentially the same as



Villamizar, et al.          Standards Track                    [Page 20]

RFC 2769           Routing Policy System Replication       February 2000


   that performed by the originating repository (except that the
   repository is free to use a different "transfer-method" from the one
   that was in the received transaction.

7.3.1  Explicitly Requesting Transactions

   A repository may also explicitly request one or more transactions
   belonging to a specified originating repository.  This is useful for
   catching up after a repository has been off-line for a period of
   time.  It is also useful for mirrors which intermittently poll a
   repository for recently received transactions.

   To request a range of transactions from a peer, a repository must
   send a "transaction-request" meta-object to the peer.  A
   "transaction-request" meta-object may contain the following
   attributes:

   transaction-request  This attribute is mandatory and single.  It
      contains the name of the database whose transactions are being
      requested.

   sequence-begin  This attribute is optional and single.  It contains
      the sequence number of the first transaction being requested.

   sequence-end  This attribute is optional and single.  It contains the
      sequence number of the last transaction being requested.

   Upon receiving a "transaction-request" object, a repository performs
   the following actions.  If the "sequence-begin" attribute is not
   specified, the repository assumes the request first sequence number
   to be 1.  The last sequence number is the lesser of the value of the
   "sequence-end" attributed and the highest completed transaction in
   the corresponding database.  The repository then, in order, transmits
   the requested range of transactions.  Each transaction is prepared
   exactly according to the rules for redistribution specified in
   Section 7.3.

   After transmitting all the transactions, the peer repository must
   send a "transaction-response" meta-object.  This meta-object has the
   following attributes:

   transaction-response  This attribute is mandatory and single.  It
      contains the name of the database whose transactions are were
      requested.