rfc1102.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1102          Policy Routing in Internet Protocols          May 1989


   to avoid billing for packets that are lost between that AR and the
   destination, it is necessary to have some form of lost packet
   reporting, which travels backward through system decrementing the
   counters of all the intervening ARs.  If single point collection is
   performed, then the usage meters can be put in the destination AR,
   and periodically propagated to the billing AR, if that is a different
   region.

   The discussion of lost packets makes clear an important relationship
   between billing and policy.  If a Policy Route takes packets through
   a region of known unreliability, the regions preceding it on the path
   may be quite unwilling to forgive the charges for packets which have
   successfully crossed their region, only to be lost further down the
   route.  A billing policy is a way of asserting that one region wishes
   to divorce itself from the reliability behavior of another region.
   The conditions in the policy terms, and corresponding policy routes,
   must therefore be able to capture two distinct conditions.  The first
   is whether or not there exists a bilateral agreement between two ARs
   by which one agrees to be the collection agent for the other.  The
   concatenation of a number of these agreements permits a single
   collection point to be used for the entire policy route.  The other
   condition is whether or not the AR will accept packet and byte counts
   from the next AR downstream as the basis of billing, or whether the
   AR insists that the billing be based on the counts at the exit point
   of this AR.  This condition allows an AR to build a wall between it
   and a subsequent unreliable AR.  One can imagine certain regions
   agreeing to carry traffic into unreliable regions, but only
   grudgingly, knowing that the result is going to be user frustration
   which may be directed to all the ARs indiscriminately.  The use of a
   specific policy condition can make clear to the end user which ARs do
   not view themselves as interworking harmoniously.

   To enforce these mechanisms, the abstract PR which is included in the
   packet must be augmented with a number of conditions.  First, for
   each AR there is a 3-way flag which describes whether the billing
   should be separately collected for the region, propagated back to the
   source (which corresponds to the normal telephone company paradigm),
   or propagated towards the destination (which corresponds to a collect
   call).  Second, there is a flag which indicates whether the region is
   expected to accept from the next region downstream the packet and
   byte counts as the basis of billing.  Third, there must be a charge
   code, a unique number somewhat resembling a credit card number to
   which bills may be sent.  The Policy Terms in the Gateways must
   similarly be augmented to permit verification.  The management of the
   charge code, insuring its uniqueness and preventing its abuse, is
   discussed later.

   These conditions, which relate to agreements between two ARs, are



Clark                                                          [Page 12]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   somewhat different from the conditions previously discussed, such as
   time of day.  Conditions relating to AR agreements will be called
   "bilateral conditions," while the others are called "global
   conditions."  Note that even though bilateral conditions relate to
   the agreement between two ARs, they can have global effects.

7. Gateway Selection

   In Section Two, this memo proposed that the end point should specify
   an abstract Policy Route, as a series of ARs, and the Policy Gateway
   at the entry to each AR should convert the next hop to a concrete
   route, selecting the Policy Gateway to exit from this region into the
   next.  It turns out that this selection is not entirely devoid of
   policy concerns, and some additional conditions are required in the
   Policy Terms in order to make this operate properly.

   In order that each Policy Gateway be able to select the next Policy
   Gateway on the route, it is necessary to have a table which lists all
   of the potential Policy Gateways that connect together adjacent
   regions.  Presumably, this information is very slowly changing, and
   is not difficult to propagate.  The more dynamic information that is
   needed is whether each of these gateways is up.  It is therefore
   necessary that all of the Policy Gateways attached to a given AR must
   run a local up-down algorithm, one which hopefully can determine not
   only that each of the other gateways is up, but that its interfaces
   are up and that it is properly forwarding traffic.  It is slightly
   complicated to design such a test.  However, we do not have to design
   a strategy for propagating this information globally, because it is
   only needed by the other Policy Gateways attached to each region.

   The policy matter related to concrete routes arises if there are
   several gateways connecting two administrative regions.  As described
   so far, the exit Policy Gateway from any region (which is the entry
   Policy Gateway for the next region) is selected by the entry Policy
   Gateway for that region.  In other words, each region may select its
   exit gateway, but has no control over its entry gateway.  There are
   certain circumstances where a particular region might insist on being
   able to control the entry gateway used.  Imagine two parallel transit
   regions, one which charges incrementally for service, the other of
   which provides its service as a free good.  Obviously, from the point
   of view of the user, it is desirable to minimize the use of the
   charging AR, and maximize the use of the free AR.  But this may lead
   to gross overloads in the free AR, and apparent discrimination
   against the charging AR.  The owner of the free AR, therefore, might
   choose to impose a policy which says that it can be used only to
   reach certain points which are not directly connected to the AR which
   bills for its service, and the traffic must enter the free AR at the
   closest point to the destination.  In other words, the free AR



Clark                                                          [Page 13]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   requires that it be allowed to choose its entry gateway so that it
   minimizes its costs (which are not, in fact, being billed), with the
   intent of shifting as much as possible of the cost onto the other
   network.

   By adding more bilateral conditions to the Policy Terms and the
   Policy Route in the packet, it is possible to control the various
   options for Policy Gateway selection.  At each boundary between ARs,
   there are only a limited number of ways to select the Policy Gateway.
   Either it is selected by the entry side, by the exit side, or by some
   collaborative algorithm specified through a bilateral agreement.
   (There might be several such algorithms, which requires the
   possibility of more complexity in the specification.  In particular,
   if two adjacent ARs have agreed to use a common routing metric for
   some type of service, they may agree to make a common routing based
   on this metric.)

   Allowing the policy gateway to be selected by the AR which is on the
   far side of the gateway represents an interesting implementation
   problem.  It would be possible to send some message in advance of the
   packet, which requests the next AR to select its entry gateway.  To
   do this, it would figure out what its exit gateway would be, and then
   figure backwards to minimize its costs (for example) to select the
   potential entry gateway back into the immediate region.  This is
   complicated to describe, and would probably be complicated to
   implement.  One way to focus the problem is to observe that routes
   are bi-directional, because a packet flow is bi-directional, and it
   is very desirable that the packets from both directions follow the
   same route.  Once a packet has come back along the reverse route, the
   gateway from which it emerges is precisely the gateway which should
   be used for future traffic in the other direction.  But each gateway,
   in either the forward or reverse direction, must remember a decision
   made by another AR.

   For this to work it is necessary that gateways not be stateless.  If
   each Policy Gateway maintains a cache of recently computed Policy
   Routes, in particular remembering the result of computing the gateway
   for each abstract route, then by simply determining whether or not
   the forward direction or the reverse direction is allowed to
   constrain the gateway across this boundary, both policies can be
   enforced.  But this requires building gateways with state, which has
   not been culturally acceptable in the Internet.  I therefore consider
   as a separate topic the virtues of state in Policy Gateways. I
   believe that fairly simple algorithms exist to set up the required
   bindings in the Policy Gateways, but that problem is a matter for
   later study.





Clark                                                          [Page 14]

RFC 1102          Policy Routing in Internet Protocols          May 1989


8. Flow States

   The previous section suggested that the gateway needed to maintain
   state in order to tie together the forward and reverse halves of a
   flow.  This solved the particular problem of tying together the
   routing decision which had been made in each direction, so that they
   could be used in the other.  There are, in fact, a number of reasons
   why the two halves of the flow should be tied together.

   - There is considerable overhead in accounting and collecting for the
     usage.  It is clearly desirable to have both halves of the flow
     metered jointly.

   - If the route is not bi-directional, then a failure in the node
     produces a uni-directional link.  Uni-directional links are known
     to cause anomalous behavior in protocols.

   - As part of resource management, it may be desirable for
     intermediate nodes to pass flow control information back to the
     source of the flow.  If identifiable reverse-direction packets
     are passing through the gateway, then this information can be
     piggy-backed onto those packets.

   An additional advantage of maintaining state in the gateway is that
   it will greatly reduce the overhead of dealing with incoming packets.
   There are a number of decisions which the Policy Gateway must make
   which are a part of forwarding a packet: it must validate the Policy
   Route against its terms, it must create or modify an accounting
   record, and it must select the next Policy Gateway.  It is
   unreasonable to imagine performing these tasks from scratch for each
   incoming packet.  Once these decisions have been made, the results
   should be cached, so that they can be used for subsequent packets.

   The stateless gateway was proposed as part of the Internet design in
   order to insure a robust architecture.  If the gateway has no state,
   then a crash of a gateway cannot endanger an on-going connection.  If
   there is state in a gateway, and that state information is lost
   because of a crash, then it is possible that a flow would be
   disrupted.

   In moving from a gateway with no state to a gateway which caches
   information, it is necessary to ensure that the cached information
   can be lost and reconstructed.  The idea of keeping in gateways only
   that state which can be easily reconstructed I call "soft state."







Clark                                                          [Page 15]

RFC 1102          Policy Routing in Internet Protocols          May 1989


9. Synthesis and Selection of Policy Routes

   In this proposal, a packet contains a Policy Route, which is verified
   by each Policy Gateway along the way.  This section discusses how the
   Policy Route is created in the first place.

   PR creation cannot be done totally automatically by the system, but
   will in general require human judgment.  Policies, after all, are
   matters of human concern.  The approach to PR creation is thus a
   joint one, in which the system provides support to the persons
   setting policy.

   Most commonly, the desired PR will be selected from among those
   available by first finding all valid PRs, and then picking one that
   meets the requirements of the user and has the lowest real cost.
   These two stages will be called synthesis and selection.

   To synthesize a PR across a sequence of ARs, one must find a Policy
   Term in each AR that would permit such a PR.  The Policy Terms in
   each adjacent AR must be compatible in their billing conditions and
   other particulars.  One can imagine finding a sequence of Policy
   Terms that match, rather like dominoes, and reach from the source to
   the destination.

   For a Policy Term at some AR to be acceptable as a part of a PR, the
   following must be true:

   - The Source and Destination Host address and UCI must match the
     term,

   - The Source and Destination AR must match the term,

   - The Entry and Exit AR must match the adjacent AR in the route,

   - The conditions in the term relating to the adjacent AR (e.g.,
     billing) must match the conditions in the term from that region.

   These conditions, of course, are exactly what the Policy Gateway
   would test in validating the PR when it is used.

   As the route is synthesized from matching terms, the global
   conditions of each term are noted, and the combination of these
   become the condition under which the PR is valid.  As a starting
   point of the synthesis the user may have indicated constraints on the
   acceptable conditions in order to limit the candidate terms in the
   synthesis.

   The result of PR synthesis, which is somewhat similar to the



Clark                                                          [Page 16]

RFC 1102          Policy Routing in Internet Protocols          May 1989


   computation in a link-state routing algorithm where each Policy Term
   represents an abstract link, is a potentially long list of possible
   PRs to each destination AR, each with attached conditions.  The
   selection process must identify one of these which is actually to be
   used.  The selection can be based on the conditions, and on the cost
   of each PR.

   To determine the cost, it must be possible to ask each AR to identify
   the cost of using that Policy Term in the context of this particular
   set of Entry and Exit ARs.  Either there must be an architected
   protocol for reporting these costs, or the task of cost determination
   must be left to humans to perform outside the system.  The problem
   with architected cost reporting is that while some ARs may bill using
   real dollars, others may bill in terms of abstract usage
   authorizations which have no meaning outside that AR.  Even so, I
   believe that we should attempt to define a representation for
   reporting the billing basis associated with each AR.  This is a
   matter for later study.

   While PR synthesis may be an automated process, selection probably is
   not.  While cost minimization will help prune the list, and some
   routes may be rejected automatically on the basis of conditions, part
   of the selection will in general require human judgment.  This
   observation, together with the observation that PR synthesis may be
   costly, suggests first that synthesis and selection cannot be done