rfc1125.txt

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

   *  HIGH LEVEL PROTOCOL
   Usage may be restricted to a specific high level protocol such as
   mail or file transfer. (Alternatively, such policies can be
   implemented as source/destination policies by configuring a host(s)
   within an AD as an application relay and composing policy terms that
   allow inter-AD access to only that host.)

   *  RESOURCE LIMIT
   There may be a limit on the amount of traffic load a source may
   generate during a particular time interval, e.g., so many packets in
   a day, hour, or minute.

   *  AUTHENTICATION REQUIREMENTS
   Conditions may be specified regarding the authenticability of
   principal identifying information. Some ADs might require some form
   of cryptographic proof as to the identity and affiliations of the
   principal before providing access to critical resources.

   The above policy types usually exist in combination for a particular
   AD, i.e., an AD's policies might express a combination of transit,
   source/destination, and QOS restrictions. This taxonomy will evolve
   as PR is applied to other domains.

   As will be seen in Section 6.3 an AD can express its charging and



Estrin                                                         [Page 11]

RFC 1125                  Policy Requirements              November 1989


   access policies in a single syntax. Moreover, both stub and transit
   policies can co-exist. This is important since some ADs operate as
   both stub and transit facilities and require such hybrid control.

6.2 TAXONOMY OF CHARGING POLICIES

   Stub and transit charging policies  may specify the following
   parameters:

   *  UNIT OF ACCOUNTING (e.g., dollars or credits).
   *  BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt).
   *  ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte).
   *  WHO IS CHARGED OR PAID (e.g., originator of packet,
      immediate neighbor from whom packet was received, destination
      of packet, a third party collection agent).
   *  WHOSE PACKET COUNT is used (e.g., source, destination, the
      transit AD's own count, the count of some upstream or
      downstream AD).
   *  BOUND ON CHARGES (e.g., to limit the  amount that a stub
      AD is willing to spend, or the amount that a transit AD is
      willing to carry.)

   The enforcement of these policies may be carried out during route
   synthesis or route selection [4].

6.3  EXAMPLE POLICY STATEMENTS

   The following policy statements were collected in the fall of 1988
   through interviews with representatives of the federal agencies most
   involved in supporting internetworking. Once again we emphasize that
   these are not official policy statements. They are presented here to
   provide concrete examples of the sort of policies that agencies would
   like to enforce.

   Expressing policies as Policy Terms (PTs)

   Each policy is described in English and then expressed in a policy
   term (PT) notation suggested by Dave Clark in [4].  Each PT
   represents a distinct policy of the AD that synthesized it.  The
   format of a PT is:

    [(H{src},AD{src},AD{ent}),(H{dst},AD{dst},AD{exit}),UCI, Cg,Cb]

   Hsrc stands for source host, ADsrc for source AD, ADent for entering
   AD (i.e., neighboring AD from which traffic is arriving directly),
   Hdst for destination host, ADdst for destination AD, ADexit for exit
   AD (i.e.,neighboring AD to which traffic is going directly), UCI for
   user class identifier, and Cg and Cb for global and bilateral



Estrin                                                         [Page 12]

RFC 1125                  Policy Requirements              November 1989


   conditions, respectively. The purpose of a PT is to specify that
   packets from some host, H{src}, (or a group of hosts) in a source AD,
   AD{src}, are allowed to enter the AD in question via some directly
   connected AD, AD{ent}, and exit through another directly connected
   AD, AD{exit}, on its way to a host, H{dst}, (or a group of hosts) in
   some destination AD, AD{dst}.  User Class Identifier (UCI) allows for
   distinguishing between various user classes, e.g., Government,
   Research, Commercial, Contract, etc.  Global Conditions (Cg)
   represent billing and other variables.  Bilateral Conditions (Cb)
   relate to agreements between neighboring ADs, e.g., related to
   metering or charging.  In the example policy terms provided below we
   make use of the following abbreviations: Fricc for
   {DOE,NASA,DCA,NSF}, F for Federal Agency, Re for Regional, U for
   University, Co for Commercial Corporation, and Cc for Commercial
   Carrier. A hyphen, -, means no applicable matches.

   By examining a PT we can identify the type of policy represented, as
   per the taxonomy presented earlier.

   *  If an AD specifies a policy term that has a null (-) entry for
      the ADexit, then it is disallowing transit for some group of users,
      and it is a transit policy.

   *  If an AD specifies a  policy term that lists itself
      explicitly as ADsrc or ADdst, it is expressing restrictions on who
      can access particular resources within its boundaries, or on who inside
      can obtain external access. In other words the AD is expressing a
      source/destination policy.

   *  If ADexit or ADentr is specified then the policy expressed is an
      exit/entrance path policy.

   *  If the global conditions include charging, QOS, resource
      guarantee,  time of day, higher level application, resource limit, or
      authentication related information it is obviously a charging, QOS,
      resource guarantee, temporal, higher level application, resource
      limit, or authentication policy, respectively.

   As seen below, any one PT typically incorporates a combination of
   policy types.

6.3.1  THE FRICC

   In the following examples all policies (and PTs) are symmetrical
   under the assumption that communication is symmetrical.






Estrin                                                         [Page 13]

RFC 1125                  Policy Requirements              November 1989


NATIONAL SCIENCE FOUNDATION (NSF)

   1.  NSF will carry traffic for any host connected to a F/Re network
   talking to any other host connected to a F/Re via any F/Re entry and
   exit network, so long as there is it is being used for research or
   support. There is no authentication of the UCI and no per packet
   charging.  NSFnet is a backbone and so does not connect directly to
   universities or companies...thus the indication of {F/Re} instead of
   {F/Re/U/Co} as ADent and ADexit.

   [NSF1:  (*, {F/Re}, {F/Re})(*, {F/Re}, {F/Re}){research,support}
   {unauthenticated UCI,no-per-pkt charge}{}]

   2.  NSF will carry traffic to user and expert services hosts in NSF
   AD to/from any F/Re AD, via any F/Re AD. These are the only things
   that directly connect to NSFnet.

   [NSF2: ({User svcs, Expert Svcs},{NSF},{F/Re})(*,{F/Re},{-}){}{}{}]

DEPARTMENT OF ENERGY (DOE)

   1.  DOE will carry traffic to and from any host directly connected to
   DOE so long as it is used for research or support. There is no
   authentication of the UCI and no per packet charging.

   [DOE1: (*,DOE,-)(*,*,*){research,support}
   {unauthenticated UCI,no-per-packet charge}{}]

   2.  DOE will carry traffic for any host connected to a F/Re network
   talking to any other host connected to a F/Re via any F/Re entry and
   exit network without regard to the UCI. There is no authentication of
   the UCI and no per packet charging. (in other words DOE is more
   restrictive with its own traffic than with traffic it is carrying as
   part of a resource sharing arrangement.)

   [DOE2: (*,{F/Re},{F/Re})(*,{F/Re},{F/Re}){}
   {unauthenticated UCI, no-per-pkt charge}{}]

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION (NASA)

   1.  Nasa will accept any traffic to/from members of the Nasa AD. But
   no transit. No UCI authentication and no per packet charge.

   [NASA1: (*,*,*)(*,Nasa,-){Nasa-research, support}
   {unauthenticated UCI,no-per-packet-charge}{}]

   2.  Nasa will carry transit traffic to/from other federal agency
   networks if it is in support of research, and if the total use of



Estrin                                                         [Page 14]

RFC 1125                  Policy Requirements              November 1989


   available BW by non-nasa Federal agencies is below n%. NOTE THAT this
   non-interference policy type needs some more work in terms of
   integrating it into the routing algorithms. See Section 7.

   [NASA2: (*,{F},*)(*,{F},*){research,support}
   {per-packet accounting, limited to n% of available BW}{}]

   3.  NASA will carry commercial traffic to federal and regional and
   university ADs for nasa research or support. But it will not allow
   transit. The particular entry AD is not important.

   [NASA3: (*,{Co},*} (*,{F/R/U},*) {NASA research,support}
    {unauthenticated UCI, no per packet charge}{}]

   4.  On a case by case basis NASA may provide access to its resources
   on a cost reimbursed basis. Transit traffic will not be carried on
   this basis.

    [NASA4: (*,*,-)(*,*,-){}
    {per-packet-charge, limited to n% of available BW} {}]

DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA)

   1.  DARPA will carry traffic to/from any host in DARPA AD from any
   external host that can get it there so long as UCI is research or
   support. No UCI authentication or per packet charge.

   [DARPA1: (*,*,*)(*,DARPA,-){research,support}
   {unauthenticated-UCI, no per packet charge}{}]

   2.  DARPA will carry traffic for any host connected to a F/Re/U/Co
   network talking to any other host connected to a F/Re/U/Co via any
   F/Re/U/Co entry and exit network, so long as there is it is being
   used for research or support, and the network is not heavily
   congested!!.  There is no authentication of the UCI and no per packet
   charging.  NOTE: Darpa would like to say something about the need to
   enter the Darpa AD at the point closest to the destination...but i
   don't know how to express this...

   DARPA2: (*,{F/R/U/Co},{F/R/U/Co})(*,{F/R/U/Co},{F/R/U/Co})
   {research,support}{unauthenticated-UCI,no per packet charge,
   non-interference basis}{}]

DEFENSE COMMUNICATIONS AGENCY (DCA)

   1.  DCA will not carry any transit traffic. It will only accept and
   send traffic to and from its mailbridge(s) and only from and to hosts
   on other F/Re nets. All packets are marked and charged for by the



Estrin                                                         [Page 15]

RFC 1125                  Policy Requirements              November 1989


   kilopacket.

   [DCA1:(mailbridge,DCA,-)(*,{F/Re},{F/Re}){research,support}
   {unauthenticated UCI, all incoming packets marked, per-kilopacket
   charge}{}]

6.3.2 THE REGIONALS

   Interviews with regional network administrations are now underway. In
   general their policies are still in formation due to the relatively
   recent formation of these regional networks. However, for the sake of
   illustration we provide an example of a hypothetical regional's
   network policies.

REGIONAL A

   1.  Regional A will carry traffic from/to any directly connected
   F/Re/U network to any F/Re/U network via NSF if it is for a research
   or support UCI. (NSF requires that all Regional networks only pass it
   traffic that complies with its, NSF's, policies!)

   [Regional A:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},NSF){research,support}
   {unauthenticated UCI, no-per-packet charge}{}]

REGIONAL B

   1.  Regional B will carry traffic from/to any directly connected
   F/Re/U network to any F/Re/U network via a commercial carrier
   regardless of its UCI. In this case the packets are charged for since
   the commercial carrier charges per kilopacket.

   [Regional B:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},Cc){}
   {unauthenticated UCI, per-kilopacket charge}{}]

6.3.3 CAMPUS AND PRIVATE NETWORKS

   Similar interviews should be conducted with administrators of campus
   and private networks. However, many aspects of their policies are
   contingent on the still unresolved policies of the regionals and