RFC2753 - A Framework for Policy-based Admission Control

   *  Reliability:  The sensitivity of policy control information
      necessitates reliable operation. Undetected loss of policy queries
      or responses may lead to inconsistent network control operation
      and are clearly unacceptable for actions such as billing and
      accounting. One option for providing reliability is the re-use of
      the TCP as the transport protocol.

   *  Small delays: The timing requirements of policy decisions related
      to QoS signaling protocols are expected to be quite strict. The
      PEP to PDP protocol should add small amount of delay to the
      response delay experienced by queries placed by the PEP to the
      PDP.

   *  Ability to carry opaque objects: The protocol should allow for
      delivery of self-identifying, opaque objects, of variable length,
      such as RSVP messages, RSVP policy objects and other objects that
      might be defined as new policies are introduced. The protocol
      should not have to be changed every time a new object has to be
      exchanged.

   *  Support for PEP-initiated, two-way Transactions:  The protocol
      must allow for two-way transactions (request-response exchanges)
      between a PEP and a PDP. In particular, PEPs must be able to
      initiate requests for policy decision, re-negotiation of
      previously made policy decision, and exchange of policy
      information. To some extent, this requirement is closely tied to
      the goal of meeting the requirements of RSVP-specific, policy-
      based admission control. RSVP signaling events such as arrival of
      RESV refresh messages, state timeout, and merging of reservations
      require that a PEP (such as an RSVP router) request a policy
      decision from PDP at any time. Similarly, PEP must be able to
      report monitoring information and policy state changes to PDP at
      any time.

   *  Support for asynchronous notification: This is required in order
      to allow both the policy server and client to notify each other in
      the case of an asynchronous change in state, i.e., a change that

上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] 下一页

复制本页网址和标题，发送给你QQ/Msn的好友一起分享

上一篇:RFC2754 - RPS IANA Issues

下一篇:RFC2752 - Identity Representation for RSVP