rfc2688.txt

RFC 的详细文档！

   the link-level scheduler SHOULD control how much link bandwidth is
   assigned to each class at any instant. The scheduler should assign
   bandwidth to a class according to the bandwidth reserved for the sum
   of all flows which currently have packets assigned to the class. Note
   that in the example of Section 3.3, when packets from flows A and E
   were assigned to the same class (class 1), the scheduler assigned
   more bandwidth to class 1, reflecting the fact that it was carrying
   traffic from reservations totaling 20kbit/s while the other classes
   were carrying only 10kbit/s.








Jackowski, et al.           Standards Track                    [Page 11]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


5. Security Considerations

   General security considerations for MLPPP and PPP links are addressed
   in RFC 1990 [12] and RFC 1661 [13], respectively.  Security
   considerations relevant to RSVP, used as the signaling protocol for
   integrated services, are discussed in RFC 2209 [14].

   A specific security consideration relevant to providing quality of
   service over PPP links appears when relying on either observed or
   theoretical average packet expansion during admission control due to
   bit- or byte-stuffing.  Implementations based on these packet-
   expansion values contain a potential vulnerability to denial of
   service attacks.  An adversary could intentionally send traffic that
   will result in worst case bit- or byte stuffing packet expansion.
   This in turn could result in quality of service guarantees not being
   met for other flows due to overly permissive admission control. This
   potential denial of service attack argues strongly for using a worst
   case expansion factor in admission control calculations, even for
   controlled load service.

   Beyond the considerations documented above, this document introduces
   no new security issues on top of those discussed in the companion
   ISSLL documents [1], [2] and [3] and AVT document [4].  Any use of
   these service mappings assumes that all requests for service are
   authenticated appropriately.

6. References

   [1]  Bormann, C., "Providing Integrated Services over Low-bitrate
        Links", RFC 2689, September 1999.

   [2]  Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
        2686, September 1999.

   [3]  Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
        RFC 2687, September 1999.

   [4]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
        Low-Speed Serial Links", RFC 2508, February 1999.

   [5]  Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", RFC 2211, September 1997.

   [6]  Partridge, C. and  R. Guerin, "Specification of Guaranteed
        Quality of Service", RFC 2212, September 1997.






Jackowski, et al.           Standards Track                    [Page 12]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


   [7]  Shenker, S. and J. Wroclawski, "General Characterization
        Parameters for Integrated Service Network Elements", RFC 2215,
        September 1997.

   [8]  Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
        RFC 1144, February 1990.

   [9]  B. Davie et al. "Integrated Services in the Presence of
        Compressible Flows", Work in Progress (draft-davie-intserv-
        compress-00.txt), Feb. 1999.

   [10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression
        over PPP", RFC 2509, February 1999.

   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
        Coradettim, "The PPP Multilink Protocol (MP)", RFC 1990, August
        1996.

   [13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.

   [14] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
        -- Version 1 Message Processing Rules", RFC 2209, September
        1997.
























Jackowski, et al.           Standards Track                    [Page 13]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


7. Authors' Addresses

   Steve Jackowski
   Deterministic Networks, Inc.
   245M Mt Hermon Rd, #140
   Scotts Valley, CA  95060
   USA

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


   David Putzolu
   Intel Architecture Labs (IAL)
   JF3-206-H10
   2111 NE 25th Avenue
   Hillsboro, OR 97124-5961
   USA

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


   Eric S. Crawley
   Argon Networks, Inc.
   25 Porter Road
   Littleton, MA 01460
   USA

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


   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   USA

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

Acknowledgements

   This document draws heavily on the work of the ISSLL WG of the IETF.






Jackowski, et al.           Standards Track                    [Page 14]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


Appendix A. Admission Control Considerations for POTS Modems

   The protocols used in current implementations of POTS modems can
   exhibit significant changes in link rate and delay over the duration
   of a connection. Admission control and link scheduling algorithms
   used with these devices MUST be prepared to compensate for this
   variability in order to provide a robust implementation of integrated
   services.

   Link rate on POTS modems is typically reported at connection time.
   This value may change over the duration of the connection. The v.34
   protocol, used in most POTS modems, is adaptive to link conditions,
   and is able to recalibrate transmission rate multiple times over the
   duration of a connection. Typically this will result in a small
   (~10%) increase in transmission rate over the initial connection
   within the first minute of a call. It is important to note, however,
   that other results are possible as well, including decreases in
   available bandwidth. Admission control algorithms MUST take such
   changes into consideration as they occur, and implementations MUST be
   able to gracefully handle the pathological case where link rate
   actually drops below the currently reserved capacity of a link.

   Delay experienced by traffic over POTS modems can vary significantly
   over time.  Unlike link rate, the delay often does not converge to a
   stable value.  The v.42 protocol is used in most POTS modems to
   provide link-layer reliability. This reliability, which is
   implemented via retransmission, can cause frames to experience
   significant delays.  Retransmissions also implicitly steal link
   bandwidth from other traffic. These delays and reductions in link
   bandwidth make it extremely difficult to honor a guaranteed service
   reservation. On a link that is actually lightly or moderately loaded,
   a controlled load service can to some extent accept such events as
   part of the behavior of a lightly loaded link. Unfortunately, as
   actual link utilization increases, v.42 retransmissions have the
   potential of stealing larger and larger fractions of available link
   bandwidth; making even controlled load service difficult to offer at
   high link utilization when retransmissions occur.














Jackowski, et al.           Standards Track                    [Page 15]

RFC 2688      Integrated Services Mappings Low Speed Nets September 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.



















Jackowski, et al.           Standards Track                    [Page 16]