home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rsvp-policy-arch-01.txt < prev    next >
Text File  |  1996-11-25  |  18KB  |  479 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Draft                                               Shai Herzog
  8. Expire in six months                     IBM T.J. Watson Research Center
  9. File: draft-ietf-rsvp-policy-arch-01.txt                        11/22/96
  10.  
  11.  
  12.  
  13.               Policy Control for RSVP: Architectural Overview
  14.  
  15.  
  16.  
  17. Status of Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time.  It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as "work in progress."
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  32.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  33.    Rim).
  34.  
  35. Abstract
  36.  
  37.    This memo provides insight into some possible approaches for policy
  38.    enforcement in resource reservation protocols.  We present sample
  39.    scenarios for each of these approaches as a way to demonstrate their
  40.    feasibility, and to motivate the development of  supporting
  41.    architectures.
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Shai Herzog            Expiration: December 1996                [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Internet Draft          Policy Control for RSVP            November 1996
  65.  
  66.  
  67. 1. Introduction
  68.  
  69.    Reservation protocols, by definition, discriminate between users, by
  70.    providing some users with better service at the expense of others.
  71.    Therefore, it is reasonable to expect that these protocols be
  72.    accompanied by mechanisms for controlling and enforcing access
  73.    policies.  In this document, we refer to such policies as "policy
  74.    control".  The term "policy control" is quite broad; it ranges from
  75.    simple access control to sophisticated accounting and debiting
  76.    mechanisms.
  77.  
  78.    Throughout this document we use the terms "reservation protocols" and
  79.    "RSVP" interchangeably. However, the contents of this document could
  80.    be applied to similar resource reservation protocols as well. The
  81.    current admission process in RSVP uses resource (capacity) based
  82.    admission control; we expand this model to include policy based
  83.    admission control.  Policy admission control is enforced locally at
  84.    border/policy nodes (also see [LPM]). However, the local decision may
  85.    be based on policy information provided at reservation setup time
  86.    (e.g., POLICY_DATA objects in RSVP). This information propagates
  87.    hop-by-hop by policy nodes, and may be modified by each of these
  88.    nodes (subject to the applicable agreements, and local policies).
  89.    Credentials are among the most useful and common policy information;
  90.    they allow local policies to discriminate between various usage
  91.    groups by describing the "originator/s" of the reservation request.
  92.    [Note 1]
  93.  
  94.    For scaling reasons, we concentrate on policies that follow a
  95.    bilateral-agreement model.  The bilateral model assumes that network
  96.    clouds (providers) contract with their closest point of contact
  97.    (neighbor) to establish ground rules and arrangements for access
  98.    control and accounting. These contracts are mostly local and do not
  99.    rely on global agreements.  The bilateral model has similar scaling
  100.    properties to multicast and is easier to maintain in distributed
  101.    environments.
  102.  
  103.    In this document, we outline a few sample scenarios for access
  104.    control and accounting; we provide these scenarios as motivation and
  105.    as needed context for the development of policy control architectures
  106.    for resource reservation protocols.  These scenarios are based on two
  107.    simple assumptions: (1) RSVP  provides the transport service which
  108.    carries policy control state (POLICY_DATA objects), hop-by-hop. (2)
  109. _________________________
  110. [Note 1] Clearly, in the multicast case, credentials may describe only a
  111. merged aggregate rather than the original credentials of all the end-
  112. receivers.
  113.  
  114.  
  115.  
  116.  
  117.  
  118. Shai Herzog            Expiration: December 1996                [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Internet Draft          Policy Control for RSVP            November 1996
  125.  
  126.  
  127.    Policies are enforced locally, and can be based, among other factors,
  128.    on bilateral agreements between neighboring providers, local
  129.    policies, and the contents of POLICY_DATA objects; as well as other
  130.    factors.
  131.  
  132. 2. Simple access control
  133.  
  134.    To provide simple access control, the local node attempts to match
  135.    incoming policy objects with one or more of the pre-configured
  136.    policies or bilateral agreements.
  137.  
  138.    Consider the following network scenario: one receiver from ISI and
  139.    two from MIT listen to a PARC seminar. For simplicity we limit
  140.    ourselves to receiver based access control.
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178. Shai Herzog            Expiration: December 1996                [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Internet Draft          Policy Control for RSVP            November 1996
  185.  
  186.  
  187.  
  188.           ...........                  .............
  189.          .    *ba*   .   *ba*         .             .
  190.          . S1------->A--------------->B---+ *mc*    .
  191.          .           .                .   |         .
  192.           ...........                  ...C.........
  193.            PARC                          /  BARRNet
  194.                                    *mc* /
  195.                                        /
  196.          ........        .............D.....         ........
  197.         .        .      .    *ln+ne* /      .       .        .
  198.         .   *is* . *ln* .           /       . *ne*  . *mi*   .
  199.         .   +----G------F<--------E-------->J------->K----+  .
  200.         .   |    .       .  *ln*     *ne*  .|        .    |  .
  201.          ...H....         ................. |         ....L...
  202.       Los   |                 MCINet        |             | Near
  203.       Nettos| *is*                    *sp* /         *mi* | Net
  204.      .......I....                         /        .......M...
  205.     .       |    .                 ......N..      .*r2*/ @*r3*.
  206.     .   *r1*|    .                .  *r4*|  .     .   /   @   .
  207.     .       R1   .                .      R4 .     .  R2   R3  .
  208.      ............                  .........       ...........
  209.         ISI                         Sprint             MIT
  210.  
  211.  
  212.     LEGEND:
  213.  
  214.     *xx* Credential
  215.     .... Cloud border
  216.     A..N Nodes
  217.     Si   Sender i
  218.     Ri   Receiver i
  219.  
  220.                       Figure 1: Simple access control
  221.  
  222.  
  223.    Bilateral agreements between each two neighboring providers (e.g.,
  224.    R1, R2 with ISI, ISI with LosNettos,... BARRNet with PARC) are
  225.    simple: the first provider obtains permission to make reservations
  226.    over the second provider's network. The notation PD(cr,uid)
  227.    represents a policy data object of type "cr" (credential) verifying
  228.    that the reservation is associated with uid.  Credentials may have an
  229.    underlying hierarchy; Quite often, individual end-users belong to a
  230.    stub or local service provider. These in-turn, contract with regional
  231.    service providers who connect with backbone providers. Such hierarchy
  232.    provides a natural way of aggregating receiver credentials along the
  233.    reserved tree (by rewriting and merging credentials on a hop-by-hop
  234.    basis according to locally configured conversion tables).
  235.  
  236.  
  237.  
  238. Shai Herzog            Expiration: December 1996                [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. Internet Draft          Policy Control for RSVP            November 1996
  245.  
  246.  
  247.    Figure 1 illustrates a reservation scenario.  A typical example of a
  248.    bilateral agreement could be between MCI and LosNettos: MCI would
  249.    allow the LosNettos users to use its backbone. A policy data object
  250.    PD(cr, LosNettos) would be interpreted by MCI as a green light to
  251.    accept the reservation. In this scenario, reservations from R1, R2,
  252.    and R3 carry policy data objects which propagate hop-by-hop
  253.    (encapsulated in reservation messages) toward S1.
  254.  
  255.    In this scenario, policy objects are rewritten in nodes B,D,G,I,K,
  256.    and M (which are entry points to clouds). There are two main reasons
  257.    for rewriting credentials along the reserved tree. First, effective
  258.    credentials may loose their validity when a flow crosses
  259.    administrative boundaries.  Second, for scaling reasons, large lists
  260.    of individual credentials may be merged into hierarchically higher-
  261.    level credentials.
  262.  
  263.    In our scenario, let us assume that D is configured with the
  264.    following conversion table:
  265.  
  266.    PD(cr, LosNettos)   ->   PD(cr, MCI)
  267.    PD(cr, NearNet)     ->   PD(cr, MCI)
  268.  
  269.    Node D first checks if LosNettos and NearNet are authorized to
  270.    reserve on their corresponding links and responds accordingly.
  271.    Assuming authorization is granted, it merges and rewrites these
  272.    policy objects as PD(cr, MCI) and forwards the reservation to C.
  273.  
  274.    To complicate the example, assume the conversion table was:
  275.  
  276.    PD(cr, LosNettos)   ->   PD(cr, MCI1)
  277.    PD(cr, NearNet)     ->   PD(cr, MCI2)
  278.  
  279.    Then node D would forward PD(cr, MCI1) + PD(cr, MCI2) to C instead.
  280.  
  281.    We illustrates a plausible scenario where rewriting of credentials
  282.    may only takes place at boundary nodes. What is the responsibility of
  283.    non-policy nodes? In our scenario, node E receives the following
  284.    policy data objects:  F->E: PD(cr,LosNettos) and J->E:
  285.    PD(cr,NearNet).  Because it has no authority to merge or rewrite
  286.    these credentials, node E must concatenate the two objects and send
  287.    them as-is (PD(cr,LosNettos) + PD(cr,NearNet)) to D.
  288.  
  289.    Reservations arriving with insufficient credentials are subject to
  290.    rejection. In our scenario, the arrow pointing to node J in Figure 1
  291.    illustrates J's local policy to allow only NearNet traffic. As a
  292.    result, the reservation made by R4 using the credential PD(cr,
  293.    Sprint) is rejected.
  294.  
  295.  
  296.  
  297.  
  298. Shai Herzog            Expiration: December 1996                [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. Internet Draft          Policy Control for RSVP            November 1996
  305.  
  306.  
  307. 3. Advanced reservation and preemption control
  308.  
  309.    Advanced reservations can be built on top of simple access control:
  310.    consider the case where every advanced reservation consists of a set
  311.    of bilateral agreements between different service providers,
  312.    reserving network capacity at some future period of time. When
  313.    advanced reservations are not public (i.e., only authorized users can
  314.    use them), three classes of reservations exist: (1) walk-ins (where
  315.    the session itself does not have advanced reservations, (2) advanced
  316.    reservation with unauthorized users, and (3) advanced reservation
  317.    with authorized users.  These numbers (1..3) can define a "preemption
  318.    priority" (i.e., walk-ins are preempted first, unauthorized pre-
  319.    reserved second, and authorized pre-reserved are never preempted).
  320.  
  321.    The advanced reservation scenario is almost identical to simple
  322.    access control:  let us assume that each bilateral pre-registration
  323.    is identified by a PRID (Pre-Registration confirmation ID). Policy
  324.    data objects of type AR (Advanced Reservation) would take the
  325.    following form: PD(ar, prid ,uid).  When an AR object arrives, the
  326.    local node verifies the existence of pre-reservation prid, and checks
  327.    that uid is permitted to use it. Finally, the flow is classified into
  328.    one of the above three preemptive priorities and RSVP is notified.
  329.  
  330. 4. Quota enforcement/accounting/debiting
  331.  
  332.    The simplest form of policy control performs a binary task: accept or
  333.    reject based on credentials associated with a reservation.  The next
  334.    step is to allow for more sophisticated policy enforcement that is
  335.    based on usage feedback. Here we add two additional mechanisms which
  336.    determines (1) what debiting mechanism should be used (if any), and
  337.    (2)how much should be debited for the reservation.  The following
  338.    scenarios assume a preexisting set of local accounts.  These accounts
  339.    are established by bilateral agreements that pre-purchase network
  340.    capacity and set applicable debiting rules.  The role of accounting
  341.    mechanism is to verify the availability of funds/quotas in these
  342.    accounts for maintaining the reservation.
  343.  
  344.    In multicast environments, with upstream merging, it is very likely
  345.    that a reservation will be debited against multiple network entities
  346.    that represent the aggregated credentials of the downstream
  347.    receivers.  (See node D in Figure 1.)  This raises the issue of the
  348.    "sharing model"; the "sharing model" defines how the reservation is
  349.    shared among the different policy data objects. There are many
  350.    possible manners for sharing such costs; some examples may be: (1)
  351.    Each policy object is allocated the full cost, (2) The cost is
  352.    divided equally between the different objects (3) The cost is
  353.    attributed to an individual objects according to the local policy,
  354.    and(4) The cost is allocated relative to some criteria like the
  355.  
  356.  
  357.  
  358. Shai Herzog            Expiration: December 1996                [Page 6]
  359.  
  360.  
  361.  
  362.  
  363.  
  364. Internet Draft          Policy Control for RSVP            November 1996
  365.  
  366.  
  367.    number of downstream receivers, the size of the organization, the
  368.    amount of pre-purchased capacity (remaining quota), etc.  The sharing
  369.    model, and the selection of cost allocation and actual debiting
  370.    mechanisms is a local configuration issue which is not discussed in
  371.    this document.
  372.  
  373.    We consider several accounting schemes and briefly describe three:
  374.    simple debiting, limited debiting, Edge Pricing, and MultiCost
  375.    (MCost).
  376.  
  377. Simple debiting
  378.  
  379.    Consider the following example:  lets assume that LosNettos and
  380.    NearNet each have a debit account (pre-purchased capacity) with MCI
  381.    for their traffic. When node E receives PD(cr,LosNettos) and
  382.    PD(cr,NearNet) for flow f, it must decide the following: (1) How much
  383.    should be debited for flow f, and (2) how would that debit be shared
  384.    between the account of LosNettos and NearNet. These are local
  385.    configuration issues left for service providers.  In this scenario,
  386.    the local node would attempt to perform the debiting, and would
  387.    notify RSVP of success or failure. The other aspects of the scenario
  388.    (Merging policy data objects and forwarding them) is identical to
  389.    that of simple access control.
  390.  
  391. Limited debiting (willingness to pay)
  392.  
  393.    Although we do not have a full understanding of the dynamics of
  394.    willingness-to-pay and its properties, we can outline the basic
  395.    scenario, as an extension of the simple debiting model.  Willingness
  396.    to pay is manifested as a limit on the policy object that authorizes
  397.    the debit. For instance, PD(crwp,ISI,10% of unicast) would represent
  398.    a policy data object of type crwp (Credential, Willingness to Pay),
  399.    that authorizes debiting the ISI account up to 10% of the unicast
  400.    cost. Here, the basic idea is that market forces would be the driving
  401.    force behind what users specify as their willingness to pay.
  402.  
  403. Edge Pricing
  404.  
  405.    A new paradigm, "Edge Pricing" [She96] argues that pricing of network
  406.    services can be performed at a single point which is the edge of the
  407.    network (i.e., the network access point).  Here, users only interact
  408.    (for prices and accounting) with their immediate (edge) service
  409.    provider. To price non-local traffic, the edge provider must be able
  410.    to estimate, at least, both the path and congestion costs of the
  411.    admitted traffic. In a simplistic example, geographical addresses
  412.    (e.g., in IPv6) provide an estimated path cost, and time-of-day may
  413.    provide a good estimation of congestion costs. (See [She96] for more
  414.    detailed discussion of such approximations).  Edge Pricing can be
  415.  
  416.  
  417.  
  418. Shai Herzog            Expiration: December 1996                [Page 7]
  419.  
  420.  
  421.  
  422.  
  423.  
  424. Internet Draft          Policy Control for RSVP            November 1996
  425.  
  426.  
  427.    implemented as an extension of simple debiting; Simple debiting could
  428.    determines (which account) to be debited (based on credentials) and
  429.    Edge Pricing could estimate the prices to be debited, based on
  430.    locally available information.  However, when accounting for
  431.    multicast, local information may be insufficient to estimate path
  432.    costs; multicast uses logical addresses which per-se do not reveal
  433.    the identity or location of receivers nor to they reveal the topology
  434.    of the multicast tree. This problem and a proposed accounting
  435.    solution (MultiCost or MCost) was described in [Her95]. MCost has a
  436.    unique feature:  it takes into account the benefits of sharing a
  437.    multicast tree and distributes these savings among the members of the
  438.    multicast group, according to configurable policies, basic fairness,
  439.    and equality. MCost computes the share of the multicast cost
  440.    allocated to each end-user; this cost is an important component, that
  441.    may be used for estimating multicast prices at the Edge.
  442.  
  443. 5. Acknowledgment
  444.  
  445.  
  446.    This document incorporates inputs from Deborah Estrin, Bob Braden,
  447.    and Scott Shenker and feedback from RSVP collaborators.
  448.  
  449.  
  450. References
  451.  
  452. [Her95]  S. Herzog, S. Shenker and D. Estrin, Sharing the Cost of
  453.     Multicast Trees: An Axiomatic Analysis, "Proceedings of ACM/SIGCOMM
  454.     '95", Cambridge, MA, Aug. 1995
  455.  
  456. [LPM]  S. Herzog Local Policy Modules (LPM): Policy Enforcement for
  457.     Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-
  458.     policy-lpm-01.[ps,txt], Nov. 1996.
  459.  
  460. [She96]  S. Shenker, D. Clark, D. Estrin, and S. Herzog Pricing in
  461.     Computer Networks: Reshaping the Research Agenda,
  462.     "Telecommunications Policy", Vol. 20, No. 1, 1996 also published in
  463.     "Proceedings of the Twenty-Third Annual Telecommunications Policy
  464.     Research Conference", 1995.
  465.  
  466.  
  467.  
  468. Author's Address
  469.  
  470. Shai Herzog
  471. IBM T. J. Watson Research Center,
  472. P.O. Box 704
  473. Yorktown Heights, NY 10598
  474. Phone: (914) 784-6059
  475. Email: herzog@watson.ibm.com
  476.  
  477.  
  478. Shai Herzog            Expiration: December 1996                [Page 8]
  479.