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-ext-02.txt < prev    next >
Text File  |  1997-03-20  |  33KB  |  961 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Draft                                               Shai Herzog
  8. Expiration: Oct. 1997                    IBM T.J. Watson Research Center
  9. File: draft-ietf-rsvp-policy-ext-02.txt                        Apr. 1997
  10.  
  11.  
  12.  
  13.  
  14.                    RSVP Extensions for Policy Control
  15.  
  16.  
  17.  
  18.                                 03/19/97
  19.  
  20. Status of Memo
  21.  
  22.    This document is an Internet-Draft.  Internet-Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its areas,
  24.    and its working groups.  Note that other groups may also distribute
  25.    working documents as Internet-Drafts.
  26.  
  27.    Internet-Drafts are draft documents valid for a maximum of six months
  28.    and may be updated, replaced, or obsoleted by other documents at any
  29.    time.  It is inappropriate to use Internet-Drafts as reference
  30.    material or to cite them other than as "work in progress."
  31.  
  32.    To learn the current status of any Internet-Draft, please check the
  33.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  34.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  35.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  36.    Rim).
  37.  
  38. Abstract
  39.  
  40.    This memo presents a set of extensions for supporting generic policy
  41.    based admission control in RSVP. [Note 1]
  42.  
  43.    These extensions include the standard format of POLICY_DATA objects,
  44.    a generic RSVP/Policy-Control interface, and a description of RSVP's
  45.    handling of policy events.
  46.  
  47.    This document does not advocate particular policy control mechanisms;
  48.    however, a Router/Server Policy Protocol description for these
  49.    extensions can be found in [LPM].
  50. _________________________
  51. [Note 1] This memo could be conceived as an extension to the RSVP
  52. functional specifications [RSVPSP].
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Shai Herzog              Expiration: Oct. 1997                  [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Internet Draft     RSVP Extensions for Policy Control
  65.  
  66.  
  67. Table of Contents
  68.  
  69. 1     Introduction                                                    3
  70.  
  71. 2     Policy Data Object Format                                       3
  72.  
  73.       2.1   Base Format   ........................................... 4
  74.  
  75.       2.2   Policy Data Options  .................................... 4
  76.  
  77.             2.2.1 RSVP Objects as Policy Options  ................... 5
  78.  
  79.             2.2.2 Other Options  .................................... 5
  80.  
  81. 3     RSVP/Policy Control Interface                                   6
  82.  
  83.       3.1   Synchronous vs. Asynchronous Policy Control   ........... 6
  84.  
  85.       3.2   Policy Control Services  ................................ 7
  86.  
  87.       3.3   PC Success Codes  ....................................... 10
  88.  
  89.       3.4   RSVP's Policy Actions   ................................. 11
  90.  
  91.             3.4.1 Pending Results and Asynchronous Notification   ... 11
  92.  
  93.             3.4.2 Error Signaling   ................................. 11
  94.  
  95.             3.4.3 Policy Response   ................................. 12
  96.  
  97.       3.5   Default Handling of Policy Data Objects  ................ 12
  98.  
  99. 4     Acknowledgment                                                  13
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. Shai Herzog              Expiration: Oct. 1997                  [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Internet Draft     RSVP Extensions for Policy Control
  125.  
  126.  
  127. 1. Introduction
  128.  
  129.    RSVP, by its definition, discriminates between users, by providing
  130.    some users with better service at the expense of others. Therefore,
  131.    it is reasonable to expect that RSVP be accompanied by mechanisms for
  132.    controlling and enforcing access and usage policies.  Historically,
  133.    when RSVP Ver. 1 was developed, the knowledge and understanding of
  134.    policy issues was in its infancy. As a result, Ver. 1 of the RSVP
  135.    Functional Specifications[RSVPSP] left a place holder for policy
  136.    support in the form of POLICY_DATA objects. However, it  deliberately
  137.    refrained from specifying mechanisms, message formats, or providing
  138.    insight into how policy enforcement should be carried out. This
  139.    document is intended to fill in this void.
  140.  
  141.    The current RSVP Functional Specification describes the interface to
  142.    admission (traffic) control that is based "only" on resource
  143.    availability. In this document we describe a set of extensions to
  144.    RSVP for supporting policy based admission control as well, in one
  145.    atomic operation. The scope of this document is limited to these
  146.    extensions; a discussion of accounting and access control policies
  147.    for resource reservation protocols can be found in [Arch] and a
  148.    description of a router-server Policy Protocol for these extensions
  149.    can be found in [LPM].
  150.  
  151. 2. Policy Data Object Format
  152.  
  153.    The following replaces section A.13 in [RSVPSP].
  154.  
  155.    POLICY_DATA objects are carried by RSVP messages and contain policy
  156.    information. All policy-capable nodes (at any location in the
  157.    network) can generate, modify, or remove policy objects in compliance
  158.    with local policies. [Note 2]
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169. _________________________
  170. [Note 2] Core nodes can add policy objects to RSVP messages, even when
  171. none was provided by senders or receivers.  Most likely, this would be
  172. based on specific network topology properties (e.g., incoming port ID).
  173.  
  174.  
  175.  
  176.  
  177.  
  178. Shai Herzog              Expiration: Oct. 1997                  [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Internet Draft     RSVP Extensions for Policy Control
  185.  
  186.  
  187.    2.1 Base Format
  188.  
  189.       POLICY_DATA class=14
  190.  
  191.       o    Type 1 POLICY_DATA object: Class=14, C-Type=1
  192.  
  193.            +-------------+-------------+-------------+-------------+
  194.            |  Length                   | POLICY_DATA |      1      |
  195.            +---------------------------+-------------+-------------+
  196.            |  Data Offset              | Flags       | 0 (reserved)|
  197.            +---------------------------+-------------+-------------+
  198.            |                                                       |
  199.            // Option List                                         //
  200.            |                                                       |
  201.            +-------------------------------------------------------+
  202.            |                                                       |
  203.            // Policy Element List                                 //
  204.            |                                                       |
  205.            +-------------------------------------------------------+
  206.  
  207.            Data Offset: 16 bits
  208.  
  209.                 The offset in bytes of the data portion (from the first
  210.                 byte of the object header).
  211.  
  212.            Flags: 8 bits
  213.  
  214.                 0x01  PCF_Updt
  215.                       A modified object, don't check against previous one
  216.                 0x02  PCF_Fragment
  217.                       This is a fragment of a PD object
  218.  
  219.            Reserved: 8 bits
  220.  
  221.                 Always 0.
  222.  
  223.            Option List
  224.  
  225.                 The list of options and their usage is defined in
  226.                 Section 2.2.
  227.  
  228.            Policy Element List
  229.  
  230.                 The contents of policy elements is opaque to RSVP and
  231.                 its internal format is only known to the Local Policy
  232.                 Module (LPM). (See Section 3 and [LPM]).
  233.  
  234.                 Policy Elements have the following format:
  235.  
  236.  
  237.  
  238. Shai Herzog              Expiration: Oct. 1997                  [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. Internet Draft     RSVP Extensions for Policy Control
  245.  
  246.  
  247.                 +-------------+-------------+-------------+-------------+
  248.                 |  Length                   |  P-type                   |
  249.                 +---------------------------+---------------------------+
  250.                 |                                                       |
  251.                 // Policy information  (Opaque to RSVP)                //
  252.                 |                                                       |
  253.                 +-------------------------------------------------------+
  254.  
  255.  
  256.    2.2 Policy Data Options
  257.  
  258.       This section describes a set of options that may appear as options
  259.       in POLICY_DATA objects. All policy options appear as RSVP objects;
  260.       some use their valid original format while others appear as NULL
  261.       objects.
  262.  
  263.       2.2.1 RSVP Objects as Policy Options
  264.  
  265.          The following objects retain the same format specified in
  266.          [RSVPSP] however, they gain different semantics when used
  267.          inside POLICY_DATA objects.
  268.  
  269.          FILTER_SPEC object (list)
  270.  
  271.               The set of senders associated with the POLICY_DATA object.
  272.               If none is provided, the policy information is assumed to
  273.               be associated with all the flows of the session.
  274.  
  275.          RSVP_HOP Object(s)
  276.  
  277.               The RSVP_HOP object identifies the neighbor/peer policy-
  278.               capable node that constructed the policy object. When
  279.               policy is enforced at border nodes, peer policy nodes may
  280.               be several RSVP hops away from each other.
  281.  
  282.               If an RSVP_HOP object follows either an INTEGRITY or
  283.               RSVP_HOP objects it identifies the destination policy
  284.               node. [Note 3]
  285.  
  286.               If a destination RSVP_HOP and the address of the receiving
  287.               node do not match, the entire POLICY_DATA object is
  288. _________________________
  289. [Note 3] This RSVP_HOP may be used to ensure the POLICY_DATA object is
  290. delivered to the targeted policy node.  It may be used to emulate
  291. unicast delivery in multicast Path messages.  It also helps prevent
  292. using a policy object in other parts of the network (replay attack).
  293.  
  294.  
  295.  
  296.  
  297.  
  298. Shai Herzog              Expiration: Oct. 1997                  [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. Internet Draft     RSVP Extensions for Policy Control
  305.  
  306.  
  307.               ignored.
  308.  
  309.          INTEGRITY Object
  310.  
  311.               The INTEGRITY object provides guarantees that the object
  312.               was not compromised. It follows the rules from [Bak96],
  313.               and is calculated over the SESSION object, POLICY_DATA
  314.               object, and the message type field [Note 4]
  315.                as if they formed one continuous in-order message,
  316.               without any alignment.  This concatenation is designed to
  317.               prevent copy and replay attacks of POLICY_DATA objects
  318.               from other sessions, flows, message types or even other
  319.               network locations.
  320.  
  321.               The RSVP_HOP and INTEGRITY options are mutually exclusive
  322.               since the INTEGRITY object already contains the sending-
  323.               system address.  If neither is present, the policy data is
  324.               implicitly assumed to have been constructed by the
  325.               RSVP_HOP indicated in the RSVP message itself (i.e., the
  326.               neighboring RSVP node is policy-capable).
  327.  
  328.  
  329.       2.2.2 Other Options
  330.  
  331.          All options that do not use a valid RSVP object format, should
  332.          use the NULL RSVP object format with different CType values.
  333.          This document defines only one such option, however, several
  334.          other may be considered in future versions.  (e.g.,
  335.          Fragmentation, NoChange, etc.).
  336.  
  337.          o    Policy Refresh Multiplier
  338.  
  339.               Some policies may have looser timing constraints than
  340.               RSVP, and therefore may allow for lower refresh frequency.
  341.               If the Policy Refresh Multiplier option is present, policy
  342.               is refreshed only once in "Multiplier" RSVP refreshes, for
  343.               "Duplicates" times.
  344.  
  345.               +-------------+-------------+-------------+-------------+
  346.               |             8             |    0        |     1       |
  347.               +-------------+-------------+-------------+-------------+
  348.               | Multiplier  | Duplicates  | Reserve (0)               |
  349.               +-------------+-------------+---------------------------+
  350.  
  351. _________________________
  352. [Note 4] As it appears in RSVP's common header.
  353.  
  354.  
  355.  
  356.  
  357.  
  358. Shai Herzog              Expiration: Oct. 1997                  [Page 6]
  359.  
  360.  
  361.  
  362.  
  363.  
  364. Internet Draft     RSVP Extensions for Policy Control
  365.  
  366.  
  367.               For example, for "Multiplier=16" and "Duplicates=3", the
  368.               policy should be refreshed on RSVP's refreshes number
  369.               1,2,3,16,17,18,...
  370.  
  371. 3. RSVP/Policy Control Interface
  372.  
  373.    Conceptually, this section belong to Section 3.10.3 titled
  374.    "RSVP/Policy Control Interface" of the RSVP functional
  375.    specification[RSVPSP].
  376.  
  377.    Policy control in RSVP is modeled as a set of functions which are
  378.    provided by a separate component known as Local Policy Module.  The
  379.    LPM controls the use of POLICY_DATA objects and provides
  380.    authorization information to RSVP.
  381.  
  382.    3.1 Synchronous vs. Asynchronous Policy Control
  383.  
  384.       RSVP must routinely consult the LPM for policy decisions.  The
  385.       consultation can follow one of two models: Synchronous or
  386.       Asynchronous. In the Synchronous model, when RSVP calls a
  387.       particular service, it must block until the call is completed.
  388.       (even if it takes substantial time). In the Asynchronous model,
  389.       the call never blocks; delayed results are communicated back to
  390.       RSVP through an upcall.  The asynchronous model is harder to
  391.       support, since RSVP must be able to halt incomplete tasks, save
  392.       their context, and complete them later, when results become
  393.       available, however, it has significantly better scaling
  394.       properties.
  395.  
  396.       Query results may be commonly delayed when policy decisions are
  397.       performed by an external server (See [LPM]).  Consider a case
  398.       where an average query takes 10ms; a synchronous RSVP/policy
  399.       implementation would be roughly limited to less than 100 unicast
  400.       flows and even much less for multicast flows.
  401.  
  402.       Since the two models provide the same functionality, and differ
  403.       only in performance; each RSVP implementation is free to select
  404.       the model best fitting its needs. RSVP may choose the synchronous
  405.       model by specifying a NULL as a cdp parameter when calling a
  406.       service.
  407.  
  408.    3.2 Policy Control Services
  409.  
  410.       o    Common Parameters
  411.  
  412.            The following is a list of common parameters (shared by
  413.            several policy control functions.
  414.  
  415.  
  416.  
  417.  
  418. Shai Herzog              Expiration: Oct. 1997                  [Page 7]
  419.  
  420.  
  421.  
  422.  
  423.  
  424. Internet Draft     RSVP Extensions for Policy Control
  425.  
  426.  
  427.            session,  filter_spec_list and shr_ind
  428.  
  429.                 The set of flows to which the POLICY_DATA object
  430.                 applies, and an indication whether they are shared.
  431.  
  432.            rsvp_hop
  433.  
  434.                 The peer policy node, as well as the local LIH
  435.                 connecting to it. The (rsvp_hop includes the local
  436.                 lih),
  437.  
  438.            message_type
  439.  
  440.                 The direction and type of message that carried the
  441.                 POLICY_DATA object.
  442.  
  443.            resv_handle and  resv_flowspec
  444.  
  445.                 Information regarding the current/desired level of
  446.                 reservation and traffic characteristics.
  447.  
  448.            cbp and  giveup_time
  449.  
  450.                 A pointer (address) of the Control Block. RSVP provides
  451.                 this address when making service calls. This value is
  452.                 echoed back to RSVP with the completion notification
  453.                 upcall.  Giveup_time is the maximal period RSVP is
  454.                 willing to wait; If results are still unavailable after
  455.                 this period, RSVP should receive an upcall with failure
  456.                 results (and timer-expired error).
  457.  
  458.  
  459.       o    Call: PC_InPolicy   (message_type, rsvp_hop, session,
  460.                                 shr_ind, filter_spec_list,
  461.                                 in_policy_objects,
  462.                                 resv_handle,
  463.                                 resv_flowspec,
  464.                                 refresh_period,
  465.                                 cbp, giveup_time)
  466.                                 -> RCode
  467.  
  468.            RSVP calls PC_InPolicy for all incoming messages; However, it
  469.            is acceptable for implementations to turn off policy
  470.            processing for messages other than Path and Resv, when they
  471.            don't carry any POLICY_DATA objects. [Note 5]
  472. _________________________
  473. [Note 5] It is highly desirable to authorize Tear and Error messages
  474. even when they don't carry policy objects.  However, since the risk from
  475.  
  476.  
  477.  
  478. Shai Herzog              Expiration: Oct. 1997                  [Page 8]
  479.  
  480.  
  481.  
  482.  
  483.  
  484. Internet Draft     RSVP Extensions for Policy Control
  485.  
  486.  
  487.            The LPM verifies any incoming policy objects (if included)
  488.            and provides an authorization decision. [Note 6]
  489.  
  490.            If the incoming message is authorized, RSVP continues its
  491.            normal processing. If it is rejected, RSVP drops the message
  492.            entirely (as if it was never received), and sends the
  493.            appropriate error message (with a policy failure error code).
  494.            With RSVP's soft-state management, the consequences of
  495.            dropping the incoming message is that the existing state
  496.            (Path or Resv) begins to age and would eventually time-out.
  497.            [Note 7]
  498.  
  499.  
  500.            Reservations may also be authorized with a warning which
  501.            marks them as preemptable.  A preemptable reservation may be
  502.            canceled at any time by admission control to make room for
  503.            another more important reservation.  (See "TC_Preempt()" and
  504.            the discussion of service preemption in [RSVPSP].)
  505.  
  506.            Parameter refresh-period has the same value and semantics as
  507.            in RSVP.
  508.  
  509.       o    Call: PC_OutPolicy  (message_type, rsvp_hop_list, session,
  510.                                 shr_ind, filter_spec_list,
  511.                                 max_pd, avail_pd,
  512.                                 cbp, giveup_time,
  513.                                 out_policy_objects)
  514.                                 -> RCode
  515.  
  516.            Before RSVP finalizes an any outgoing RSVP message it calls
  517.            PC_OutPolicy() to prepare outgoing objects for the a
  518.            specified flow.  RSVP specifies the desired maximal object
  519.            size ("max_pd"), and the available space within the current
  520.            RSVP control message ("avail_pd"). [Note 8]
  521. _________________________
  522. relaxed authorization is limited to denial of service for a single flow,
  523. the decision is left at the discretion of local administrators.
  524.  
  525. [Note 6] To prevent code duplication, PC_AuthCheck() may be called
  526. internally.
  527.  
  528. [Note 7] An incoming messages may fail authorization simply because it
  529. lacks a particular policy object which was lost in transit.  This
  530. approach is consistent with RSVP's state management rules.
  531.  
  532. [Note 8] "avail_pd" must be at least the size of a POLICY_DATA object
  533. without a data portion or the call would fail.
  534.  
  535.  
  536.  
  537.  
  538. Shai Herzog              Expiration: Oct. 1997                  [Page 9]
  539.  
  540.  
  541.  
  542.  
  543.  
  544. Internet Draft     RSVP Extensions for Policy Control
  545.  
  546.  
  547.             The filter_spec_list includes the set of filters
  548.            corresponding to the reserved sources.
  549.  
  550.            When the filter_spec_list includes multiple filters (either
  551.            because of a shared reservation or an aggregated policy over
  552.            multiple FF) individual outgoing hops may be associated with
  553.            different sets of filter_specs.  RSVP must build the
  554.            filter_spec_list as a union of all filter_spec lists over all
  555.            outgoing hops. (All reserved sources) The LPM computes
  556.            individual per-hop filter_spec lists as the intersection of
  557.            this list with the set of sources upstream to a specific
  558.            previous hop.  (Previous-hop information is obtained from
  559.            incoming Path messages.)  A NULL filter_spec_list represents
  560.            "all" sources (i.e., WF).
  561.  
  562.            The call returns a list of outgoing POLICY_DATA objects for
  563.            each rsvp_hop.
  564.  
  565.       o    Call: PC_AuthCheck  (message_type, session,
  566.                                 shr_ind, filter_spec_list,
  567.                                 resv_desc list,
  568.                                 full_list_ind,
  569.                                 cbp, giveup_time)
  570.                                 -> RCode
  571.  
  572.            Parameter resv_desc provides a list of reservation
  573.            descriptions.  This description is made of three components:
  574.            lih, resv_handle, and  resv_flowspec.
  575.  
  576.            In the upstream direction (e.g., Resv) authorization may need
  577.            to be checked on multiple LIHs (all reservations for a flow).
  578.            In such cases, status queries can be perform separately for
  579.            each LIH, once for all LIHs, or anything in between.
  580.            full_list_indication must be set at the last of
  581.            PC_AuthCheck() query of the series. [Note 9]
  582.  
  583.  
  584.            Authorization can be verified on both the Path and Resv
  585.            directions.  When the message_type is an upstream type (Resv,
  586.            Resv Tear, Path Err) the lih is assumed to be an outgoing
  587.            interface and reservation status is checked. However, when
  588. _________________________
  589. [Note 9] When policies are interdependent across LIHs (as when the cost
  590. is shared among downstream receivers), full_list_ind notifies the server
  591. that the list of reserved LIH is complete and that it can safely compute
  592. the status of these reservations.
  593.  
  594.  
  595.  
  596.  
  597.  
  598. Shai Herzog              Expiration: Oct. 1997                 [Page 10]
  599.  
  600.  
  601.  
  602.  
  603.  
  604. Internet Draft     RSVP Extensions for Policy Control
  605.  
  606.  
  607.            the message_type is an downstream type (Path, Path Tear, Resv
  608.            Err), the lih is assumed to be an incoming interface and
  609.            Path-sending authorization is checked.
  610.  
  611.            Authorization checks are usually triggered by the arrival of
  612.            a new message; these are handled transparently by the input
  613.            processing call PC_InPolicy(). In a synchronous, when an
  614.            upcall mechanism is not supported, RSVP must verify the
  615.            status of reservations before refreshing them.
  616.  
  617.       o    Call: PC_Init       (K, upcall,... )
  618.                                 -> RCode
  619.  
  620.            This call initializes the LPM and sets specific RSVP/policy
  621.            configuration parameters.  K is the soft-state multiplier for
  622.            refresh-period (see [RSVPSP]) and upcall registers a routine
  623.            that may be called by the LPM to notify RSVP on policy
  624.            changes. (See next item)
  625.  
  626.       o    Call: upcall        (event_type, cbp, message_type,
  627.                                 lih, rsvp_hop list, session,
  628.                                 shr_ind, filter_spec_list,
  629.                                 out_policy_objects,
  630.                                 RCode)
  631.  
  632.            Event_type determines the original call type (if applicable).
  633.            cbp is an echo of the cbp provided by RSVP when making the
  634.            original call. RSVP may use this pointer to locate the
  635.            original context of the call.
  636.  
  637.            RCode uses the same values specified in this document, as it
  638.            would for the original calls. Notice that the upcall
  639.            parameters are a superset of the parameters used by all the
  640.            non-blocking PC calls.
  641.  
  642.       o    Call: PC_DelState   (message_type, rsvp_hop,
  643.                                 session, filter_spec_list,
  644.                                 op_type)
  645.                                 -> RCode
  646.  
  647.            This call affects all the state associated with a particular
  648.            multicast (or unicast) branch. It is used for route changes,
  649.            blockade state other instantaneous state change performed by
  650.            RSVP.  When applicable parameters are NULL, an aggregate of
  651.            the state is affected (across all values of the NULL-ed
  652.            parameter).  For example, PC_DelState(NULL, session, NULL,
  653.            NULL, PC_delete) would purge all the policy state associated
  654.            with "session".
  655.  
  656.  
  657.  
  658. Shai Herzog              Expiration: Oct. 1997                 [Page 11]
  659.  
  660.  
  661.  
  662.  
  663.  
  664. Internet Draft     RSVP Extensions for Policy Control
  665.  
  666.  
  667.            Parameter "op_type" is the requested type of state change:
  668.  
  669.  
  670.            PC_Delete :        Purge state.
  671.            PC_Block  :        Blockade (ignore) state
  672.            PC_Unblock:        Unblock state.
  673.  
  674.  
  675.    3.3 PC Success Codes
  676.  
  677.       The return code (RCode) provides policy feedback to RSVP, it is
  678.       made of three separate return variables: [Note 10]
  679.  
  680.  
  681.       o    Function return value:
  682.  
  683.            0: Success
  684.  
  685.                 The call was completed successfully.  For PC_AuthCheck()
  686.                 and  PC_InPolicy() it also signals the authorization of
  687.                 the RSVP operation (e.g., Reservation, Path, Tear, etc.)
  688.                 RSVP need not check the PC_flags or PC_errno.
  689.  
  690.            1: Pending
  691.  
  692.                 The requested results are delayed.  Should these results
  693.                 become available or the giveup_time expires, the
  694.                 notification upcall would signal RSVP.
  695.  
  696.            2: Warning
  697.  
  698.                 Same as success except that there is a non-fatal warning
  699.                 and RSVP must check the PC_flags for further
  700.                 instructions.
  701.  
  702.            3: Policy failure
  703.  
  704.                 Policy authorization for the RSVP operation has failed.
  705.                 RSVP should invoke its standard error reporting
  706.                 mechanism (PathErr or ResvErr).
  707.  
  708.  
  709.       o    "PC_errno":
  710. _________________________
  711. [Note 10] This is only an initial list, we expect that part to change as
  712. policy control matures.
  713.  
  714.  
  715.  
  716.  
  717.  
  718. Shai Herzog              Expiration: Oct. 1997                 [Page 12]
  719.  
  720.  
  721.  
  722.  
  723.  
  724. Internet Draft     RSVP Extensions for Policy Control
  725.  
  726.  
  727.            An external variable (similar to the "errno" in Unix) which
  728.            provides specific error (reason) code.
  729.  
  730.       o    "PC_flags":
  731.  
  732.            An external variable with flags that advise RSVP about
  733.            required operations:
  734.  
  735.            0x01  PC_RC_ModState  
  736.  
  737.                 The incoming POLICY_DATA object contains an update.
  738.                 RSVP must immediately initiate update forwarding
  739.                 procedures.
  740.  
  741.            0x02  PC_RC_Resp   
  742.  
  743.                 RSVP must immediately initiate a message. The type of
  744.                 requested message is placed in the PC_errno variable and
  745.                 corresponds to message type values in the RSVP common
  746.                 header.
  747.  
  748.            0x04  PC_RC_Preempt   
  749.  
  750.                 Only for Resv incoming objects. RSVP should inform the
  751.                 local admission control that the reservation is of lower
  752.                 priority and can be preempted, if necessary.
  753.  
  754.  
  755.    3.4 RSVP's Policy Actions
  756.  
  757.       The PC success codes, and especially "PC_Flags" advise RSVP about
  758.       appropriate required actions. This section describes these actions
  759.       in greater detail.
  760.  
  761.       3.4.1 Pending Results and Asynchronous Notification
  762.  
  763.          For various reasons the LPM may need to consult an external
  764.          entity (e.g., server) for partial policy processing.  (For a
  765.          description of a router/server protocol see [LPM]).  For
  766.          efficiency reasons, RSVP must not be forced to wait idly while
  767.          external policy processing takes place.  Instead, A
  768.          configurable option permits calls to PC_AuthCheck() or
  769.          PC_OutPolicy() to terminate with a "pending" return value
  770.          whenever results are delayed (for any reason).
  771.  
  772.          The following steps take place when RSVP receives a pending
  773.          return value:
  774.  
  775.  
  776.  
  777.  
  778. Shai Herzog              Expiration: Oct. 1997                 [Page 13]
  779.  
  780.  
  781.  
  782.  
  783.  
  784. Internet Draft     RSVP Extensions for Policy Control
  785.  
  786.  
  787.          o    RSVP halts the current operation, saves its state (linked
  788.               to the cbp), and moves to the next task.
  789.  
  790.          o    Once results are available or the giveup_time expires
  791.               [Note 11]
  792.  
  793.               the LPM "wakes up" RSVP by calling the notification
  794.               upcall.
  795.  
  796.          o    The wakeup call provides results, context, and the cbp
  797.               (see Section 3.2).
  798.  
  799.          o    RSVP resumes the previously halted operation and uses the
  800.               provided context parameters as if they were returned by
  801.               the original (previously pending) call.
  802.  
  803.       3.4.2 Error Signaling
  804.  
  805.          Policy errors are reported by either ResvErr or PathErr
  806.          messages with a policy failure error code (specified in
  807.          [RSVPSP]).  Policy error message must include a POLICY_DATA
  808.          object; the object contains details of the error type and
  809.          reason.  If none is provided, the error message should not be
  810.          sent.
  811.  
  812.          If a multicast reservation fails, RSVP should not attempt to
  813.          discover which reservation caused the failure (as it would do
  814.          for blockade state). Instead, it should attempt to deliver the
  815.          policy ResvErr to ALL downstream hops.  The LPM would limit the
  816.          error distribution by providing outgoing objects only to
  817.          "culprit" next-hops; if the LPM performs local repair [Note 12]
  818.           it can prevent the further distribution of ResvErr or PathErr
  819.          messages.
  820.  
  821.          The LPM should internally implement blockade state style
  822.          mechanism for similar reasons as RSVP (preventing an
  823.          unauthorized reservation from forcing other valid reservations
  824.          to fail).  This document does not define this mechanism and
  825.          assumes it would be policy-implementation specific.
  826.  
  827. _________________________
  828. [Note 11] If results are still unavailable at giveup_time, the answer is
  829. assumed to be failure (for AuthCheck) or no output (for OutPolicy).
  830.  
  831. [Note 12] Local repair can be performed by substituting the failed
  832. POLICY_DATA object with a different one.
  833.  
  834.  
  835.  
  836.  
  837.  
  838. Shai Herzog              Expiration: Oct. 1997                 [Page 14]
  839.  
  840.  
  841.  
  842.  
  843.  
  844. Internet Draft     RSVP Extensions for Policy Control
  845.  
  846.  
  847.       3.4.3 Policy Response
  848.  
  849.          The LPM can initiate an immediate outgoing RSVP message (Path,
  850.          Resv, etc.) by setting the flag PC_RC_Response and providing
  851.          the number of the requested RSVP message in the PC_errno
  852.          variable. [Note 13]
  853.  
  854.          This mechanism is useful when the appropriate RSVP message is
  855.          either scheduled for a significantly later time, or not at all.
  856.          When the PC_RC_Response flag is set, RSVP, should schedule the
  857.          requested outgoing message as if its refresh timer has expired;
  858.          for non-refreshed messages like ResvErr, RSVP should act as if
  859.          they were just received.
  860.  
  861.          This mechanism allows policies that require an immediate
  862.          confirmation by scheduling a reverse-direction message with a
  863.          confirmation POLICY_DATA object.
  864.  
  865.    3.5 Default Handling of Policy Data Objects
  866.  
  867.       It is generally assumed that policy enforcement (at least in its
  868.       initial stages) is likely to concentrate on border nodes between
  869.       autonomous systems. Consequently, policy objects transmitted at
  870.       one edge of an autonomous cloud may traverse intermediate non-
  871.       policy-capable RSVP nodes.  The minimal requirement from a non-
  872.       policy-capable RSVP node is to forward POLICY_DATA objects
  873.       embedded in the appropriate outgoing messages, as-is (without
  874.       modifications) according to the following rules:
  875.  
  876.       o    POLICY_DATA objects are to be forwarded as is, in the same
  877.            type of RSVP messages in which they arrived.
  878.  
  879.       o    Multicast merging (splitting) nodes:
  880.  
  881.            In the upstream direction:
  882.  
  883.                 Applicable incoming POLICY_DATA objects are
  884.                 concatenated, and the list is forwarded with the
  885.                 upstream message.
  886.  
  887.            On the downstream direction:
  888.  
  889.                 A copy of all applicable incoming objects is forwarded
  890. _________________________
  891. [Note 13] The value of the PC_errno corresponds to message type values
  892. in the RSVP common header.
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Shai Herzog              Expiration: Oct. 1997                 [Page 15]
  899.  
  900.  
  901.  
  902.  
  903.  
  904. Internet Draft     RSVP Extensions for Policy Control
  905.  
  906.  
  907.                 with each downstream message.
  908.  
  909.  
  910.       The same rules apply to unrecognized policies (sub-objects) within
  911.       the POLICY_DATA object. However, since that can only occur in a
  912.       policy-capable node, it is the responsibility of the LPM and not
  913.       RSVP.
  914.  
  915. 4. Acknowledgment
  916.  
  917.  
  918.    This document incorporates inputs from Lou Berger, Bob Braden,
  919.    Deborah Estrin, Roch Guerin, Dimitrios Pendarakis, Raju Rajan, and
  920.    Scott Shenker.  It also reflects feedback from many other RSVP
  921.    collaborators.
  922.  
  923.  
  924. References
  925.  
  926. [Bak96]  F. Baker.  RSVP Cryptographic Authentication "Internet-Draft",
  927.     draft-ietf-rsvp-md5-02.txt, 1996.
  928.  
  929. [RSVPSP]  R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
  930.     Resource ReSerVation Protocol (RSVP) Version 1 Functional
  931.     Specification.  "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt],
  932.     Nov. 1996.
  933.  
  934. [LPM]  S. Herzog Local Policy Modules (LPM): Policy Enforcement for
  935.     Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-
  936.     policy-lpm-01.[ps,txt], Nov. 1996.
  937.  
  938. [Arch]  S. Herzog Accounting and Access Control Policies for Resource
  939.     Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
  940.     arch-01.[ps,txt], Nov. 1996.
  941.  
  942.  
  943. Author's Address
  944.  
  945. Shai Herzog
  946. IBM T. J. Watson Research Center,
  947. P.O. Box 704
  948. Yorktown Heights, NY 10598
  949.  
  950. Phone: (914) 784-6059
  951. Email: herzog@watson.ibm.com
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958. Shai Herzog              Expiration: Oct. 1997                 [Page 16]
  959.  
  960.  
  961.