RFC2753 - A Framework for Policy-based Admission Control

   reservation request should still be accepted, installed, and
   forwarded to allow continued normal RSVP processing. In particular,
   when a PDP sends back an error, it specifies that:

      1. the message that generated the admission control request should
      be processed further as usual, but an error message (or warning)
      be sent in the other direction and include the policy objects
      supplied in that error message

      2. or, specifies that an error be returned, but the RSVP message
      should not be forwarded  as usual.

4.3. Interactions between PEP, LPDP, and PDP at a RSVP router

   All the details of RSVP message processing and associated
   interactions between different elements at an RSVP router (PEP, LPDP)
   and PDP are included in separate documents [3,8]. In the following, a
   few, salient points related to the framework are listed:

   *  LPDP is optional and may be used for making decisions based on
      policy elements handled locally. The LPDP, in turn, may have to go
      to external entities (such as a directory server or an
      authentication server, etc.) for making its decisions.

   *  PDP is stateful and  may make decisions even if no policy objects
      are received (e.g., make decisions based on information such as
      flowspecs and session object in the RSVP messages). The PDP may
      consult other PDPs, but discussion of inter-PDP communication and
      coordination is outside the scope of this document.

   *  PDP sends asynchronous notifications to PEP whenever necessary to
      change earlier decisions, generate errors etc.

   *  PDP exports the information useful for usage monitoring  and

上一页 [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