rfc2990.txt

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

   create an external view of a compound network as a single subnetwork.
   From this external perspective the network can be perceived as two
   boundary service points, ingress and egress.  The advantage of this
   approach is that there exists the potential to eliminate the
   requirement for per-flow state and per-flow processing on the
   interior elements of such a network, and instead provide aggregate
   service responses.

   One approach is for applications to use RSVP to request that their
   flows be admitted into the network.  If a request is accepted, it
   would imply that there is a committed resource reservation within the
   IntServ-capable components of the network, and that the service
   requirements have been mapped into a compatible aggregate service
   class within the DiffServ-capable network [7].  The DiffServ core
   must be capable of carrying the RSVP messages across the DiffServ
   network, so that further resource reservation is possible within the
   IntServ network upon egress from the DiffServ environment.  The
   approach calls for the DiffServ network to use per-flow multi-field
   (MF) classifier, where the MF classification is based on the RSVP-
   signaled flow specification.  The service specification of the RSVP-
   signaled resource reservation is mapped into a compatible aggregate
   DiffServ behavior aggregate and the MF classifier marks packets
   according to the selected behavior.  Alternatively the boundary of
   the IntServ and DiffServ networks can use the IntServ egress to mark
   the flow packets with the appropriate DSCP, allowing the DiffServ
   ingress element to use the BA classifier, and dispense with the per-
   flow MF classifier.

   A high precision end-to-end QoS model requires that any admission
   failure within the DiffServ network be communicated to the end
   application, presumably via RSVP.  This allows the application to
   take some form of corrective action, either by modifying it's service
   requirements or terminating the application.  If the service
   agreement between the DiffServ network is statically provisioned,
   then this static information can be loaded into the IntServ boundary
   systems, and IntServ can manage the allocation of available DiffServ
   behavior aggregate resources.  If the service agreement is




Huston                       Informational                     [Page 20]

RFC 2990            Next Steps for QoS Architecture        November 2000


   dynamically variable, some form of signaling is required between the
   two networks to pass this resource availability information back into
   the RSVP signaling environment.

6. Conclusions

   None of these observations are intended to be any reason to condemn
   the QoS architectures as completely impractical, nor are they
   intended to provide any reason to believe that the efforts of
   deploying QoS architectures will not come to fruition.

   What this document is intended to illustrate is that there are still
   a number of activities that are essential precursors to widespread
   deployment and use of such QoS networks, and that there is a need to
   fill in the missing sections with something substantial in terms of
   adoption of additional refinements to the existing QoS model.

   The architectural direction that appears to offer the most promising
   outcome for QoS is not one of universal adoption of a single
   architecture, but instead use a tailored approach where aggregated
   service elements are used in the core of a network where scalability
   is a major design objective and use per-flow service elements at the
   edge of the network where accuracy of the service response is a
   sustainable outcome.

   Architecturally, this points to no single QoS architecture, but
   rather to a set of QoS mechanisms and a number of ways these
   mechanisms can be configured to interoperate in a stable and
   consistent fashion.

7. Security Considerations

   The Internet is not an architecture that includes a strict
   implementation of fairness of access to the common transmission and
   switching resource.  The introduction of any form of fairness, and,
   in the case of QoS, weighted fairness, implies a requirement for
   transparency in the implementation of the fairness contract between
   the network provider and the network's users.  This requires some
   form of resource accounting and auditing, which, in turn, requires
   the use of authentication and access control.  The balancing factor
   is that a shared resource should not overtly expose the level of
   resource usage of any one user to any other, so that some level of
   secrecy is required in this environment

   The QoS environment also exposes the potential of theft of resources
   through the unauthorized admission of traffic with an associated
   service profile.  QoS signaling protocols which are intended to




Huston                       Informational                     [Page 21]

RFC 2990            Next Steps for QoS Architecture        November 2000


   undertake resource management and admission control require the use
   of identity authentication and integrity protection in order to
   mitigate this potential for theft of resources.

   Both forms of QoS architecture require the internal elements of the
   network to be able to undertake classification of traffic based on
   some form of identification that is carried in the packet header in
   the clear.  Classifications systems that use multi-field specifiers,
   or per-flow specifiers rely on the carriage of end-to-end packet
   header fields being carried in the clear.  This has conflicting
   requirements for security architectures that attempt to mask such
   end-to-end identifiers within an encrypted payload.

   QoS architectures can be considered as a means of exerting control
   over network resource allocation.  In the event of a rapid change in
   resource availability (e.g. disaster) it is an undesirable outcome if
   the remaining resources are completely allocated to a single class of
   service to the exclusion of all other classes.  Such an outcome
   constitutes a denial of service, where the traffic control system
   (routing) selects paths that are incapable of carrying any traffic of
   a particular service class.

8. References

   [1]  Bradner, S., "The Internet Standards Process- Revision 3", BCP
        9, RFC 2026, October 1996.

   [2]  Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A.,
        Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
        Version 1 Applicability Statement", RFC 2208, September 1997.

   [3]  Braden. R., Clark, D. and S. Shenker, "Integrated Services in
        the Internet Architecture: an Overview", RFC 1633, June 1994.

   [4]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
        Weiss, "An Architecture for Differentiated Services", RFC 2475,
        December 1998.

   [5]  Baker, F., Iturralde, C., Le Faucher, F., Davie, B.,
        "Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in
        Progress.

   [6]  Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
        November 2000.







Huston                       Informational                     [Page 22]

RFC 2990            Next Steps for QoS Architecture        November 2000


   [7]  Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer,
        M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A
        Framework for Integrated Services Operation Over DiffServ
        Networks", RFC 2998, November 2000.

   [8]  "Quality of Service Technical Overview", Microsoft Technical
        Library, Microsoft Corporation, September 1999.

   [9]  "Resource Reservation Protocol API (RAPI)", Open Group Technical
        Standard, C809 ISBN 1-85912-226-4, The Open Group, December
        1998.

   [10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
        Flows", RFC 2007, September 1997.

   [11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting:
        Background", RFC 1272, November 1991.

9.  Acknowledgments

   Valuable contributions to this document came from Yoram Bernet, Brian
   Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.

10. Author's Address

   Geoff Huston
   Telstra
   5/490 Northbourne Ave
   Dickson ACT 2602
   AUSTRALIA

   EMail: [e-mail]



















Huston                       Informational                     [Page 23]

RFC 2990            Next Steps for QoS Architecture        November 2000


11.  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.



















Huston                       Informational                     [Page 24]