rfc2749.txt

中、英文RFC文档大全打包下载完全版 .

                            <Decision: Replacement, POLICY-DATA1>

   Here, the PDP decided to allow the forwarding of the Path message and
   provided the appropriate policy-data object for interface if1.

   Next, a WF Resv message from receiver R2 arrives on interface if2.

       PEP --> PDP   REQ := <Handle C> <Context: in & allocation, Resv>
                            <In-interface if2>
                            <ClientSI: all objects in Resv message
                             including RSpec1 >

       PDP --> PEP   DEC := <Handle C>
                            <Context: in, Resv>
                            <Decision: command, Install>
                            <Context: allocation, Resv>
                            <Decision: command, Install>
                            <Decision: Stateless, priority=5>

       PEP --> PDP   RPT := <handle C> <Commit>

   Here, the PDP approves the reservation and assigned it preemption
   priority of 5. The PEP responded with a commit report.

   The PEP needs to forward the Resv message upstream toward S1:

       PEP --> PDP   REQ := <Handle E> <Context: out, Resv>
                            <out-interface if3>
                            <Client info: all objects in outgoing Resv>






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


       PDP --> PEP   DEC := <Handle E>
                            <Context: out, Resv>
                            <Decision: command, Install>
                            <Decision: replacement, POLICY-DATA2>

   Note: The Context object is part of this DEC message even though it
   may look redundant since the REQ specified only one context flag.

   Next, a new WF Resv message from receiver R3 arrives on interface if2
   with a higher RSpec (Rspec2). Given two reservations arrived on if2,
   it cannot perform a request with multiple context flags, and must
   issue them separately.

   The PEP re-issues an updated handle C REQ with a new context object
   <Context: in , Resv>, and receives a DEC for handle C.

       PEP --> PDP   REQ := <Handle F> <Context: in , Resv>
                            <In-interface if2>
                            <ClientSI: all objects in Resv message
                             including RSpec2 >

       PDP --> PEP   DEC := <Handle F> <Context: in , Resv>
                            <Decision: command, Install>

       PEP --> PDP   REQ := <Handle G> <Context: allocation, Resv>
                            <In-interface if2>
                            <ClientSI: all objects in merged Resv
                             including RSpec2 >

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

       PEP --> PDP   RPT := <handle G> <Commit>

   Given the change in incoming reservations, the PEP needs to forward a
   new outgoing Resv message upstream toward S1. This repeats exactly
   the previous interaction of Handle E, except that the ClientSI
   objects now reflect the merging of two reservations.

   If an ResvErr arrives from S1, the PEP maps it to R3 only (because it
   has a higher flowspec: Rspec2) the following takes place:

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




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


       PDP --> PEP   DEC := <Handle H> <Context: in, ResvErr>
                            <Decision: command, Install>

       PEP --> PDP   REQ := <Handle I> <Context: out, ResvErr>
                            <Out-interface if2>
                            <ClientSI: all objects in outgoing ResvErr>

       PDP --> PEP   DEC := <Handle I>
                            <Context: out, ResvErr>
                            <Decision: command, Install>
                            <Decision: Replacement, POLICY-DATA3>

   When S2 joins the session by sending a Path message, incoming and
   outgoing Path requests are issued for the new Path. A new outgoing
   Resv request would be sent to S2.

6  References

   [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC
              2750, January 2000.

   [RAP]      Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
              for Policy Based Admission Control", RFC 2753, January
              2000.

   [COPS]     Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
              A. Sastry, "The COPS (Common Open Policy Service)
              Protocol", RFC 2748, January 2000.

   [RSVP]     Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
              Specification", RFC 2205, September 1997.



















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


7  Author Information and Acknowledgments

   Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
   Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan,
   and Raj Yavatkar, for their valuable contributions.

   Jim Boyle
   Level 3 Communications
   1025 Eldorado Boulevard
   Broomfield, CO 80021

   Phone: [phone]
   EMail: [e-mail]


   Ron Cohen
   CISCO Systems
   4 Maskit St.
   Herzeliya Pituach 46766 Israel

   Phone: [phone]
   EMail: [e-mail]


   David Durham
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124

   Phone: [phone]
   EMail: [e-mail]


   Raju Rajan
   AT&T Labs Research
   180 Park Ave., P.O. Box 971
   Florham Park, NJ 07932

   Phone: [phone]
   EMail: [e-mail]











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


   Shai Herzog
   IPHighway, Inc.
   55 New York Avenue
   Framingham, MA 01701

   Phone: [phone]
   EMail: [e-mail]


   Arun Sastry
   Cisco Systems
   4 The Square
   Stockley Park
   Uxbridge, Middlesex UB11 1BN
   UK

   Phone: [phone]
   EMail: [e-mail]

































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


8  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Herzog, et al.              Standards Track                    [Page 17]