rfc1102.txt

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

   by proper engineering internal to the AR.  Precisely because
   conditions must be propagated globally, attempting to base a
   condition on a highly dynamic parameter is liable to lead to system
   instability.

4.4. Ownership of Policy Gateways

   In Section 1, all the resources of the network were described as
   being partitioned among the ARs.  This statement does not extend to
   the Policy Gateways, which sit on the boundary between ARs.  Either
   the Policy Gateway must be composed of two physical halves, connected
   by a wire, or there must be a joint agreement for the ownership and
   operation of the gateway.  This is a matter for further study.

5. Examples of Policy Terms

   This section presents examples of how policy terms would be used to
   express a range of practical policies.  In order to give examples, it
   is necessary to define a notation for policy terms.  The following is
   not necessarily the most compact form, but will be sufficient for
   some simple examples.







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


        A Policy Term will be expressed as follows:

        ((Hs,ARs,ARent),(Hd,ARd,ARexit),UCI,Cg)

   where:

        Hs is the source host address,
        ARs is the source AR,
        ARent is the entry AR,



   and these three values comprise the first "element" of the term,
   describing the permitted access looking toward the source.
   Similarly, for the destination, there is an element describing the
   host address, the adjacent AR, and the ultimate AR.

   In addition to the two directional elements of the term, there is
   global information:

        UCI is the User Class Id, and
        Cg are any global conditions.

   In many cases, an element will not want to constrain one of the
   values, and we will use the "*" symbol to indicate a "wild-card"
   match.

   To construct some simple examples, here is a topology, where H
   elements are hosts, G elements are Policy Gateways, and Numbered
   elements are ARs.

      H1 ---  1 --- G1 -----  2 ------ G2 ----- 3 ----- H2
              |                                 |
              |                                 |
              |                                 |
              |---- G3 -----  4 ------ G4 ------|------ G5 --- 5
                              |                                |
                              |                                |
                              |                               H4
                              H3

   In this picture, there are four hosts, five gateways, and five
   Administrative Regions.

   First, consider AR two.  It has no hosts attached, and models a
   transit service, such as the NSF network.  It may have a very simple
   policy: it will carry any traffic between universities, without
   further constraint.  If we let AR1 and AR3 be the regions of two



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


   particular universities, then its policy term could be written as:

      AR2: ((*,1,*),(*,3,*),*,*).

   This says that AR 2 agrees to carry traffic from AR 1 to AR 3,
   without concern as to the entry and exit AR, and for any hosts in
   these ARs.

   This notation works, but is very bulky, as a new term is required for
   every pair of universities.  There are several ways to compact the
   notation.  First, we can use the * and a new symbol, "-", to broaden
   the terms a bit.  For example:

      AR2: ((*,1,*),(*,*,-),*,*)

   would assert that AR 1 can use AR 2 to talk to any directly attached
   AR, where we use the "-" to mean that the exit AR must be the
   destination AR.  In other words, the destination AR must be directly
   attached to AR2.  If AR 2 only attaches to universities, then this
   would provide the proper constraint.

   Another approach is to use the User Class ID:

      AR2:((*,*,*),(*,*,*),University,*)

   says that any traffic of any sort that has the User Class of
   University is acceptable.

   Another, and perhaps most suitable notation, is to observe that the
   distinction between source and destination is actually artificial.
   While it helps in this memo to have names for the two ends, either
   end can be a source, depending on who sends the first packet. (A
   later section explores the bi-directional nature of PRs).  A more
   general form of a PR is thus to permit any number of elements.  That
   is, a Policy Term can have more than two elements, and the meaning of
   this is that a PR is valid if it uses any two of these.

   For example, if university 5 wanted to use the AR2 service, AR2 might
   write a Policy term as follows:

      AR2:((*,1,*),(*,3,*),(*,5,*),*,*)

   which would permit a policy route between hosts in any two of the ARs
   1, 3 and 5.

   All the terms so far relate to the policies of AR2.  If university 1
   wanted to subscribe to this service, and use it to reach any other
   site, it would specify terms of its own.  For example:



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


      AR1: ((*,1, -),(*,*,2),*,*).

   This term says that any host in AR 1 can use AR 2 as a path to any
   host in any AR.  Again we use the "-" notation to indicate that the
   entry AR is the same as the source AR, in this case the AR writing
   the term.

   The ARs numbered 3 and 5 are more interesting.  While 3 is directly
   attached to 2, 5 is not.  Instead, 5 has attached to 3.  If 3 wants
   to use 2 for general transit service, it must provide a term similar
   to the one provided by 1:

      AR3: ((*,3,-),(*,*,2),*,*).

   If 5 wants to use 2, more terms are required.  Since 2 is not
   directly attached, it cannot be named as the exit AR in a term
   written by 5.  The directly attached AR, 3, is all that can be named:

      AR5: ((*,5,-),(*,*,3),*,*).

   Then AR3 must agree to carry the transit traffic for 5.

      AR3: ((*,5,-),(*,*,2),*,*)

   AR3 might not want to carry all forms of transit traffic for 5, but
   only of certain sorts or to certain locations.  This could be
   expressed by restricting the previous term.  For example,

      AR3: ((*,5,-),(*,2,-),*,*)

   would permit traffic from 5 to cross 3 to reach 2, but only to hosts
   directly in those ARs.

   For some further examples, consider AR 4, which might represent the
   AR of a commercial user.  It connects together the hosts of that
   user, for example, H3, and is connected to the other environment to
   permit cross-communication.  Given the terms so far, no traffic will
   flow into this AR.

   If AR 1 wants to permit communication with AR 4, it could add:

      AR1: ((*,1,-),(*,4,-),*,*)

   This would permit communication between hosts directly in each AR,
   but no transit traffic.  In particular, H3 and H2 cannot talk.  There
   are several different terms that would permit them to talk.





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


   The direct path would be the following:

      AR4: ((*,4,-),(H2,3,-),*,*)
      AR3: ((*,3,-),(H3,4,-),*,*).

   This would permit direct connection through G4.  Note, for variety,
   that each term has been set up so that any host in the local AR can
   match, but only one host in the other AR.  The combination happens to
   permit only H3 and H2 to communicate.

   If G4 were not there, another path would be via AR 2, which could be
   permitted by suitable terms in ARs 1,2,3 and 4.

   Even if G3 and G4 exist, no transit traffic will flow across AR 4
   from 1 to 3.  Even if 1 and 3 want it to:

      AR1: ((*,1,-),(*,3,4),*,*) and
      AR3: ((*,3,-),(*,1,4),*,*),

   the lack of a term for AR4 will prevent a valid PR via that path.
   Only if AR 4 added:

      AR4:((*,1,-),(*,3,-),*,*)

   would AR 4 start serving AR a transit path from 1 to 3.

   If AR4 added:

   AR4: ((*,4,-),(*,*,*),*,*), any host in AR 4 could talk to any host
   anywhere else, but AR 4 would still not become a transit service.

   These various examples demonstrate how individual ARs can offer
   Policy Terms that can be combined to form a route.  The notation
   proposed here is probably not adequate to express the needed range of
   policies.  For example, it may be desirable to have lists of ARs as
   part of a term, as well as single values and "*".  Other notation
   might be proposed to permit exclusion of a limited set of ARs.  It
   may also be appropriate to write elements that are directional, so
   that connections can be "opened" in one direction but not in others.
   This idea is vague in a connectionless architecture, but seems to
   relate to some real policy requirements.

   In general, the problem of expressing policy terms in compact form is
   the same as the problem of constructing compact access control lists.
   There is still an ongoing argument whether access control lists
   should be ordered, and should permit exclusion, and so on.  It would
   seem that the exact same issues arise here. Some experience
   attempting to express real policies may give guidance as to the



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


   expressive power needed.

6. Cost Recovery

   Almost all of the existing Internet has been paid for as a capital
   purchase and provided to the users as a free good.  There are limited
   examples of cost recovery, but these are based on an annual
   subscription fee rather than a charge related to the utilization.
   There is a growing body of opinion which says that accounting for
   usage, if not billing for it, is an important component of effective
   resource management.  For this reason, tools for accounting and
   billing must be a central part of any policy mechanism.  However,
   precisely because the administrative regions are autonomous, we
   cannot impose a uniform form of billing policy on all of the regions.
   Some of them may continue to provide service freely, or on the basis
   of an annual fee.  Others may charge on the basis of resources
   consumed, but even here there may be variations in detail, as some
   may charge by the packet and others may charge by the byte.  Again,
   in the telephone analogy, we see a variety of billing policies, with
   both local and long distance carriers selling service either on the
   basis of a monthly fee or on a fee-per-minute of usage, with time of
   day conditions attached.  The billing problem is thus a very
   complicated one, for the user would presumably desire to minimize the
   cost, in the context of the various outstanding conditions.

   If we are actually to pay for use of services, there is also the
   problem of collection.  Using the current telephone system as an
   example, there are two strategies for collecting revenues.  One is
   the pre-divestiture mode, in which the source AR (or the destination
   AR in the case of a collect call) serves as a single collection point
   for all of the ARs involved in the call.  After divestiture, we see
   another paradigm, in which the transit AR separately bills the
   customer.

   There are many reasons to support both collection formats.  The
   primary reason for separate billing is that not all regions may wish
   to charge the user in the same units of currency.  Some regions may
   wish to charge actual dollars, while others may wish to charge using
   some form of private allocation units.  On the other hand, having a
   single point of collection is very convenient, because it eliminates
   a lot of duplicate effort in collection.  It does, however, require a
   greater degree of trust and coordination among ARs.

   Single point collection also simplifies another sticky problem, lost
   packets.  For most types of service, the user would presumably be
   offended if asked to pay for a significant number of packets
   undelivered because they have been lost before reaching the
   destination.  If each region separately bills for its traffic, then



Clark                                                          [Page 11]