rfc1102.txt

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

Network Working Group                                           D. Clark
Request for Comments: 1102        M.I.T. Laboratory for Computer Science
                                                                May 1989


                  Policy Routing in Internet Protocols

1. Status of this Memo

   The purpose of this RFC is to focus discussion on particular problems
   in the Internet and possible methods of solution.  No proposed
   solutions in this document are intended as standards for the
   Internet.  Distribution of this memo is unlimited.

2. Introduction

   An integral component of the Internet protocols is the routing
   function, which determines the series of networks and gateways a
   packet will traverse in passing from the source to the destination.
   Although there have been a number of routing protocols used in the
   Internet, they share the idea that one route should be selected out
   of all available routes based on minimizing some measure of the
   route, such as delay.  Recently, it has become important to select
   routes in order to restrict the use of network resources to certain
   classes of customers.  These considerations, which are usually
   described as resource policies, are poorly enforced by the existing
   technology in the Internet.  This document proposes an approach to
   integrating policy controls into the Internet.

   I assume that the resources of the Internet: networks, links, and
   gateways, are partitioned into Administrative Regions or ARs.  Each
   AR is governed by a somewhat autonomous administration, with distinct
   goals as to the class of customers it intends to serve, the qualities
   of service it intends to deliver, and the means for recovering its
   cost.  To construct a route across the Internet, a sequence of ARs
   must be selected that collectively supply a path from the source to
   the destination.  This sequence of ARs will be called a Policy Route,
   or PR.  Each AR through which a Policy Route passes will be concerned
   that the PR has been properly constructed.  To this end, each AR may
   wish to insure that the user of the PR is authorized, the requested
   quality of service is supported, and that the cost of the service can
   be recovered.

   In the abstract, a Policy Route is a series of ARs, which are assumed
   to be named with globally distinct identifiers.  (The requirement for
   global names for ARs suggests that the name space of ARs is flat.
   That simplifying assumption is made in this RFC, but it should be
   possible to extend the scheme described here to permit nesting of ARs



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


   to reduce the amount of global information.  The problem of adding
   structure to the space of ARs is an exercise for later study.)
   Before a PR can be used, however, it must be reduced to more concrete
   terms; a series of gateways which connect the sequence of ARs.  These
   gateways will be called Policy Gateways.

   Presently, the closest mechanism to policy routing in the Internet is
   EGP, the Exterior Gateway Protocol.  EGP was constructed to permit
   regions of the Internet to communicate reachability information, even
   though they did not totally share trust.  In this respect, the
   regions hooked together by EGP could each be viewed as Administrative
   Regions.  However, the mechanisms of EGP imposed a topological
   restriction on the interconnection of the Administration Regions.  In
   practice, this has proved unsatisfactory.  Policy matters are driven
   by human concerns, and these have not turned out to be amenable to
   topological constraints, or indeed to constraints of almost any sort.

   The proposals in this memo are designed to permit as wide a latitude
   as possible in the construction and enforcement of policies.  In
   particular, no topological restrictions are assumed.  In general, the
   approach taken in this memo is driven by the belief that since
   policies reflect human concerns, the system should primarily be
   concerned with enforcement of policy, rather than synthesis of
   policy.  The proposal permits both end points and transit services to
   express and enforce local policy concerns.

3. Policy Routes

   Almost all approaches to policy control share, to some degree, the
   idea of a Policy Route.  The distinguishing component of a policy
   approach is the procedure by which the Policy Route is synthesized.
   One approach to synthesizing routes is to associate with each
   distinct policy a subset of all the gateways in the system, and then
   run a routing algorithm across the subset of the gateways.  This
   approach has several drawbacks.  It requires a distinct routing
   computation for every policy, which may be prohibitively expensive.
   It requires the global agreement on the nature and scope of each
   policy, which is at odds with the desire of Administrative Regions to
   establish their own independent policy assertions.  Finally, it
   almost inevitably implies a topological restriction on the
   interconnection of regions.

   Another synthesis approach is to have each Policy Gateway examine
   incoming packets and determine, based on local policy constraints,
   the most appropriate next AR.  This approach might possibly work, but
   again has several drawbacks.  First, it implies a substantial amount
   of computation at each Policy Gateway.  More importantly, it removes
   the route selection from the location where it would most naturally



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


   be executed, the end-points of the connection.

   It is useful to think of the interconnected ARs as a marketplace, in
   which various services are offered and users select among these
   services to obtain packet transport.  By this analogy, it seems
   appropriate that the actual selection of the Policy Route should be
   made by the end ARs desiring to send the packets, rather than by the
   Policy Gateways.  Looking to the phone system for comparison, it is
   the customer of the phone system who selects which of the long
   distance carriers to use, whether to purchase a fixed price service
   or pay incrementally for usage, and so on.  In this proposal,
   therefore, Policy Routes are synthesized at the end point, where the
   packet originates, and are attached to packets in order to direct
   them through the appropriate series of ARs.  In other words, Policy
   Routes are a form of source routing.  The role of synthesizing a
   Policy Route is shared between the source AR and the particular
   source host.

   In this architecture, therefore, the function of the Policy Gateway
   is not to synthesize the Policy Route, but to verify it.  In the
   following sections, we will address the two questions of how a Policy
   Route is verified, and how a Policy Route is synthesized.

   In determining that Policy Routes should be synthesized at the end
   point, it is important to distinguish between those aspects of
   routing that reflect legitimate policy concerns, and those aspects of
   routing which, in reality, relate to the detailed operation of the
   ARs.  For example, if one were to represent Policy Routes using the
   existing Internet source route mechanism, which allows the end point
   to specify a series of gateways through which the packet should pass,
   the result would be that too much function has been transferred from
   the internals of the Internet to the end points.  The end point would
   have to have knowledge of exactly which gateways are up and
   operational at a particular moment, and this degree of knowledge
   cannot be justified by policy concerns.  Further, it would be
   necessary to run a systemwide gateway reachability protocol.

   This proposal attempts to strike a balance between end point
   specification of those concerns legitimately related to policy, and
   local determination in the Policy Gateways of the more specific
   details necessary for reliable operation.  This leads to a two-level
   routing model, in which the abstract Policy Route, a series of
   administrative regions, is specified by the end point as a form of
   source route, and each Policy Gateway selects the next actual Policy
   Gateway that is to be used to forward this packet.  In other words,
   the abstract Policy Route is made concrete incrementally.  This
   division of function does require that the source AR know if there
   are faults that have partitioned pairs of ARs that are normally



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


   connected together.  This implies a global reachability protocol to
   be run for the purpose of providing information to the source AR, but
   it need only concern itself at the level of ARs, not at the level of
   gateways.  In a later section on cost-recovery, the topic of gateway
   selection will be discussed in more detail.

   An objection to a scheme such as source routing is that the
   potentially bulky source route must be in every packet, and must be
   evaluated for each packet.  One solution to this performance problem
   is to employ a limited form of route setup, in which the actual
   Policy Route is carried only in the first packet of a sequence, and a
   short identifier or "handle" is included in subsequent packets of the
   sequence.  Each Policy Gateway evaluates the PR on first encounter,
   and caches the result, which is then retrieved for later packets
   using the handle in the packet.  The idea of a handle and caching,
   and the need for a form of route setup, is discussed later.

4. Verification of Policy Routes

   As a packet arrives at a Policy Gateway, attempting to enter an AR,
   the Policy Gateway must decide whether it is legitimate to forward
   this packet, and if so, at what next Policy Gateway the packet should
   exit the AR (assuming that the final destination is not within the
   AR).  The information available to the Policy Gateway to support its
   decision determines the range of policies that can be enforced.
   Determining what information is to be available is therefore a
   central feature of our proposal.

4.1. Identifying the User

   Classic routing decisions, those minimizing some cost, are typically
   driven only by the destination of the packet.  At a minimum, policy
   decisions must be based both on the source and the destination of the
   packet.  In fact, source and destination addresses may not be
   sufficient to determine policy, for an AR may support different users
   with different rights, moreover a single user may wish to exercise
   different rights at different times.  I suggest that to identify the
   user who is proposing to use this particular Policy Route, it is
   sufficient that the packets contain the source host and AR, the
   destination host and AR, and, optionally, a User Class Identifier, or
   UCI.  In a later section, I discuss how to prevent misuse of the user
   class identifier.

   In fact, the source and destination host address may not be needed to
   support the practical range of policy decisions required at
   intermediate ARs.  Only the source and destination AR information may
   be necessary.  If individual host addresses are to be used, that
   implies that intermediate ARs will want to keep track of the rights



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


   of individual hosts.  It would be much simpler if the source AR could
   be trusted to permit only the proper hosts to use certain PRs.  I
   will consider this further in a later section when I discuss the role
   of the Policy Controller.

4.2. Verifying the Route

   The packet contains an abstract Policy Route: a series of AR
   identifiers.  To validate this route, each Policy Gateway could store
   the complete selection of acceptable policy routes, and require that
   an incoming packet have a Policy Route that exactly matched one of
   the stored entries.  This degree of constraint probably overspecifies
   the situation, and causes an information explosion.  At the other end
   of the scale, Policy Gateways could simply be sensitive to the source
   AR and the destination AR.  In some cases, particularly as regards to
   billing, this does not provide sufficient constraints.  This proposal
   suggests that in deciding whether a given Policy Route is valid, a
   Policy Gateway should look at the source and destination ARs, and
   also the ARs immediately abutting the AR in question, called the
   entry and exit ARs.

   One can think of the verification information in the Policy Gateway
   as a number of templates.  Each template is associated with a valid
   set of users, as described by the source and destination host address
   and the optional User Class, and contains the four ARs described
   above, Source, Destination, Exit, and Entry.  An incoming packet
   should be forwarded if, and only if, there is a template matching the
   information in the packet.  These templates will be called Policy
   Terms.

4.3. Conditions

   The Policy Terms, as described so far, do not permit the expression
   of a realistic range of policies.  What is needed is the ability to
   attach to a Policy Term a number of conditions, which describe
   circumstances under which the term is valid.  These might include
   what type of service (TOS) is available, what times of day the term
   is valid, what accounting options are valid, and so on.  A time-of-
   day condition, for example, would permit networks, like time-sharing
   systems, to offer their off-peak capacity to a wider community.

   In general, these conditions could be quite arbitrary.  The important
   constraint on these conditions is that any condition imposed by the
   Policy Gateway must be understood by the end point, so that it can
   generate Policy Routes which will conform to the condition.  If this
   is not so, and the Policy Gateway attaches capricious conditions to
   its policy terms, then the end points will construct Policy Routes in
   good faith which are rejected, leading to a failure to obtain service



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


   and serious dissatisfaction among users.  For this reason, it is
   necessary that the nature of policy conditions be negotiated in
   advance.

   The most interesting and difficult conditions are those that relate
   to the dynamic state of the network.  An excellent example is a
   bilateral mutual aid agreement between two transit ARs in which each
   agrees to carry the load of the other if the other should go down.
   To capture this agreement, each might wish to put in Policy Terms
   with the condition that they are valid only if some other AR is non-
   functional.  In the earlier discussion of Policy Route synthesis, it
   was necessary for the ARs to run a global up-down protocol to
   describe the connectivity of ARs.  This protocol is sufficient to
   allow the Policy Gateway to know that some other AR is non-
   functional, but care is required in the dynamics of this system to
   ensure that the end point in the PR have a consistent view of the
   up-down status of the world.  Otherwise, there would be transient
   service outages, which again would lead to user dissatisfaction.

   In general, this proposal asserts that policies should not be based
   on highly dynamic phenomenon.  Administrative Regions should be
   thought of as stable entities which do not change state rapidly.
   Highly dynamic characteristics like queue length should be dealt with