rfc2749.txt

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

   equally to the Incoming as well as the Outgoing REQ context.

3.2 Expected Associations for RSVP Requests

   When making a policy decision, the PDP may consider both Resv as well
   as its matching Path state (associated state). State association is
   straightforward in the common unicast case since the RSVP flow
   includes one Path state and one Resv state. In multicast cases this
   correspondence may be more complicated, as the match may be many-to-
   many. The COPS protocol assumes that the PDP is RSVP knowledgeable
   and capable of determining these associations based on the contents
   of the Client REQ message and especially the ClientSI object.






Herzog, et al.              Standards Track                     [Page 6]

RFC 2749                  COPS usage for RSVP               January 2000


   For example, the PDP should be able to recognize activation and
   deactivation of RSVP blockade state following discrete events like
   the arrival of a ResvErr message (activate the blockade state) as
   well as the change in the outgoing Resv message.

3.3 RSVP's Capacity Admission Control: Commit and Delete

   In RSVP, the admission of a new reservation requires both an
   administrative approval (policy control) and capacity admission
   control. After being approved by both, and after the reservation was
   successfully installed, the PEP notifies the remote PDP by sending a
   report message specifying the Commit type. The Commit type report
   message signals when billing should effectively begin and performing
   heavier delayed operations (e.g., debiting a credit card) is
   permissible by the PDP.

   If, instead, a PDP approved reservation fails admission due to lack
   of resources, the PEP must issue a no-commit report and fold back and
   send an updated request to its previous state (previously installed
   reservation). If no state was previously installed, the PEP should
   issue a delete (DRQ).

3.4 Policy Control Over PathTear and ResvTear

   PathTear and ResvTear messages are not controlled by this policy
   architecture. This relies on two assumptions: First, that MD-5
   authentication verifies that the Tear is received from the same node
   that sent the initial reservation, and second, that it is
   functionally equivalent to that node holding off refreshes for this
   reservation. When a ResvTear or PathTear is received at the PEP, all
   affected states installed on the PDP should either be deleted or
   updated by the PEP.

3.5 PEP Caching COPS Decisions

   Because COPS is a stateful protocol, refreshes for RSVP Path and Resv
   messages need not be constantly sent to the remote PDP. Once a
   decision has been returned for a request, the PEP can cache that
   decision and apply it to future refreshes. When the PEP detects a
   change in the corresponding Resv or Path message, it should update
   the PDP with the new request-state. PEPs may continue to use the
   cached state until receiving the PDP response. This case is very
   different from initial admission of a flow; given that valid
   credentials and authentication have already been established, the
   relatively long RSVP refresh period, and the short PEP-PDP response
   time, the tradeoff between expedient updates and attack prevention
   leans toward expediency. However, this is really a PEP choice, and is
   irrelevant to PDPs.



Herzog, et al.              Standards Track                     [Page 7]

RFC 2749                  COPS usage for RSVP               January 2000


   If the connection is lost between the PEP and the PDP, the cached
   RSVP state may be retained for the RSVP timeout period to be used for
   previously admitted flows (but cannot be applied to new or updated
   state). If the connection can not be reestablished with the PDP or a
   backup PDP after the timeout period, the PEP is expected to purge all
   its cached decisions. Without applicable cached decision, the PEP
   must either reject the flow or resort to its LPDP (if available) for
   decisions.

   Once a connection is reestablished to a new (or the original) PDP the
   PDP may issue a SSQ request. In this case, the PEP must reissue
   requests that correspond to the current RSVP state (as if all the
   state has been updated recently). It should also include in its
   LPDPDecision the current (cached) decision regarding each such state.

3.6 Using Multiple Context Flags in a single query

   RSVP is a store-and-forward control protocol where messages are
   processed in three distinctive steps (input, resource allocation, and
   output). Each step requires a separate policy decision as indicated
   by context flags (see Section 2.2). In many cases, setting multiple
   context flags for bundling two or three operations together in one
   request may significantly optimize protocol operations.

   The following rules apply for setting multiple Context flags:

   a. Multiple context flags can be set only in two generic cases, which
      represent a substantial portion of expected COPS transactions, and
      can be guaranteed not to cause ambiguity.

      Unicast FF:

              [Incoming + Allocation + Outgoing]

      Multicast with only one Resv message received on the interface

              [Incoming + Allocation]

   b. Context events are ordered by time since every message must first
      be processed as Incoming, then as Resource allocation and only
      then as Outgoing. When multiple context flags are set, all
      ClientSI objects included in the request are assumed to be
      processed according to the latest flag. This rule applies both to
      the request (REQ) context as well as to the decision (DEC)
      context.






Herzog, et al.              Standards Track                     [Page 8]

RFC 2749                  COPS usage for RSVP               January 2000


      For example, when combining Incoming + Allocation for an incoming
      Resv message, the flowspec included in the ClientSI would be the
      one corresponding to the Resource-Allocation context (TC).

   c. Each decision is bound to a context object, which determines which
      portion of the request context it applies to. When individual
      decisions apply to different sub-groups of the context, the PDP
      should send each group of decision objects encapsulated by the
      context flags object with the context flags applicable to these
      objects set (see the examples in Section 5).

3.7 RSVP Error Reporting

   RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to
   report policy errors. While the contents of the ERROR_SPEC object are
   defined in [RSVP,RSVP-EXT], the PDP is in the best position to
   provide its contents (sub-codes). This is performed in the following
   manner: First, the PEP (RSVP) queries the PDP before sending a
   PathErr or ResvErr, and then the PDP returns the constructed
   ERROR_SPEC in the Replacement Data Decision Object.

4  Security Considerations

   This document relies on COPS for its signaling and its security.
   Please refer to section "Security Considerations" in [COPS].

   Security for RSVP messages is provided by inter-router MD5
   authentication [MD5], assuming a chain-of-trust model.  A likely
   deployment scenario calls for PEPs to be deployed only at the network
   edge (boundary nodes) while the core of the network (backbone)
   consists of PIN nodes. In this scenario MD5 trust (authentication) is
   established between boundary (non-neighboring) PEPs. Such trust can
   be achieved through internal signing (integrity) of the Policy Data
   object itself, which is left unmodified as it passes through PIN
   nodes (see [RSVP-EXT]).

5  Illustrative Examples, Using COPS for RSVP

   This section details both typical unicast and multicast scenarios.

5.1 Unicast Flow Example

   This section details the steps in using COPS for controlling a
   Unicast RSVP flow. It details the contents of the COPS messages with
   respect to Figure 1.






Herzog, et al.              Standards Track                     [Page 9]

RFC 2749                  COPS usage for RSVP               January 2000


                            PEP (router)
                        +-----------------+
                        |                 |
         R1 ------------+if1           if2+------------ S1
                        |                 |
                        +-----------------+

           Figure 1: Unicast Example: a single PEP view

   The PEP router has two interfaces (if1, if2). Sender S1 sends to
   receiver R1.

   A Path message arrives from S1:

       PEP --> PDP   REQ := <Handle A> <Context: in & out, Path>
                            <In-Interface if2> <Out-Interface if1>
                            <ClientSI: all objects in Path message>

       PDP --> PEP   DEC := <Handle A> <Context: in & out, Path>
                            <Decision: Command, Install>

   A Resv message arrives from R1:

       PEP --> PDP   REQ := <Handle B>
                            <Context: in & allocation & out, Resv>
                            <In-Interface if1> <Out-Interface if2>
                            <ClientSI: all objects in Resv message>

       PDP --> PEP   DEC := <Handle B>
                            <Context: in, Resv>
                            <Decision: command, Install>
                            <Context: allocation, Resv>
                            <Decision: command, Install>
                            <Decision: Stateless, Priority=7>
                            <Context: out, Resv>
                            <Decision: command, Install>
                            <Decision: replacement, POLICY-DATA1>

       PEP --> PDP   RPT := <Handle B>
                            <Report type: commit>

   Notice that the Decision was split because of the need to specify
   different decision objects for different context flags.








Herzog, et al.              Standards Track                    [Page 10]

RFC 2749                  COPS usage for RSVP               January 2000


   Time Passes, the PDP changes its decision:

       PDP --> PEP   DEC := <Handle B>
                            <Context: allocation, Resv>
                            <Decision: command, Install>
                            <Decision: Stateless, Priority=3>

   Because the priority is too low, the PEP preempts the flow:

       PEP --> PDP   DRQ := <Handle B>
                            <Reason Code: Preempted>

   Time Passes, the sender S1 ceases to send Path messages:

       PEP --> PDP   DRQ := <Handle A>
                            <Reason: Timeout>

5.2 Shared Multicast Flows

   This section details the steps in using COPS for controlling a
   multicast RSVP flow. It details the contents of the COPS messages
   with respect to Figure 2.

                             PEP (router)
                         +-----------------+
                         |                 |
          R1-------------+ if1         if3 +--------- S1
                         |                 |
          R2----+        |                 |
                |        |                 |
                +--------+ if2         if4 +--------- S2
                |        |                 |
          R3----+        +-----------------+


           Figure 2: Multicast example: a single PEP view

   Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2)
   and three receivers (R1, R2, R3) for the same multicast session.
   Interface if2 is connected to a shared media.  In this example, we
   assume that the multicast membership is already in place. No previous
   RSVP messages were received, and the first to arrive is a Path
   message on interface if3 from sender S1:

       PEP --> PDP   REQ := <Handle A> <Context: in, Path>
                            <In-interface if3>
                            <ClientSI: all objects in incoming Path>




Herzog, et al.              Standards Track                    [Page 11]

RFC 2749                  COPS usage for RSVP               January 2000


       PDP --> PEP   DEC := <Handle A> <Context: in, Path>
                            <Decision: command, Install>


   The PEP consults its forwarding table, and finds two outgoing
   interface for the path (if1, if2). The exchange below is for
   interface if1, another exchange would likewise be completed for if2
   using the new handle B2.

       PEP --> PDP   REQ := <Handle B1> <Context: out, Path>
                            <Out-interface if1>
                            <clientSI: all objects in outgoing Path>

       PDP --> PEP   DEC := <Handle B1>
                            <Context: out, Path>
                            <Decision: command, Install>