rfc3248.txt

RFC 的详细文档！

   behavior to traffic arriving on one port, DB traffic arriving on
   other ports is factored in as competing traffic.

   When considering DB traffic from a single input that is leaving via
   multiple ports, it is clear that the behavior is no worse than if all
   of the traffic could be leaving through each one of those ports
   individually (subject to limits on how much is permitted).

3.7 Fragmentation and Rate

   Where an ingress link has an MTU higher than that of an egress link,
   it is conceivable packets may be fragmented as they pass through a
   Diffserv hop.  However, the unpredictability of fragmentation is
   significantly counter to the goal of providing controllable QoS.
   Therefore we assume that fragmentation of DB packets is being avoided
   (either through some form of Path MTU discovery, or configuration),
   and does not need to be specifically considered in the DB behavior
   definition.









Armitage, et al.             Informational                      [Page 6]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


3.8 Interference with other traffic

   If the DB PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage DB traffic
   could inflict on other traffic.  This will be reflected in the DB
   device's burst tolerance described in section 2.1.

3.9 Micro flow awareness

   Some DB implementations may choose to provide queuing and scheduling
   at a finer granularity, (for example, per micro flow), than is
   indicated solely by the packet's DSCP.  Such behavior is NOT
   precluded by the DB PHB definition.  However, such behavior is also
   NOT part of the DB PHB definition.  Implementors are free to
   characterize and publicize the additional per micro flow capabilities
   of their DB implementations as they see fit.

3.10 Arrival rate 'R'

   In the absence of additional information, R is assumed to be limited
   by the slowest interface on the device.

   In addition, an DB device may be characterized by different values of
   R for different traffic flow scenarios (for example, for traffic
   aimed at different ports, total incoming R, and possibly total per
   output port incoming R across all incoming interfaces).

4. IANA Considerations

   This document suggests one experimental codepoint, 101111.  Because
   the DSCP is taken from the experimental code space, it may be re-used
   by other experimental or informational DiffServ proposals.

5. Conclusion.

   This document defines DB behavior in terms of a bound on delay
   variation for traffic streams that are rate shaped on ingress to a DS
   domain.  Two parameters - capped arrival rate (R) and a 'score' (S),
   are defined and related to the target delay variation bound.  All
   claims of DB 'conformance' for specific implementations of DB
   behavior are made with respect to particular values for R, S, and the
   implementation's ability to tolerate small amounts of burstiness in
   the arriving DB traffic stream.







Armitage, et al.             Informational                      [Page 7]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


Security Considerations

   To protect itself against denial of service attacks, the edge of a DS
   domain MUST strictly police all DB marked packets to a rate
   negotiated with the adjacent upstream domain (for example, some value
   less than or equal to the capped arrival rate R).  Packets in excess
   of the negotiated rate MUST be dropped.  If two adjacent domains have
   not negotiated an DB rate, the downstream domain MUST use 0 as the
   rate (i.e., drop all DB marked packets).

   Since PDBs constructed from the DB PHB will require that the upstream
   domain police and shape DB marked traffic to meet the rate negotiated
   with the downstream domain, the downstream domain's policer should
   never have to drop packets.  Thus these drops (or a summary of these
   drops) SHOULD be noted (e.g., via rate-limited SNMP traps) as
   possible security violations or serious misconfiguration.

   Overflow events on an DB queue MAY also be logged as indicating
   possible denial of service attacks or serious network
   misconfiguration.

Acknowledgments

   This document is the product of the volunteer 'EF Resolve' design
   team, building on the work of V. Jacobson, K. Nichols, K. Poduri [1]
   and clarified through discussions with members of the DiffServ
   working group (particularly the authors of [2]).  Non-contentious
   text (such as the use of DB with tunnels, the security
   considerations, etc.) were drawn directly from equivalent text in RFC
   2598.

Intellectual Properties Considerations

   To establish whether any considerations apply to the idea expressed
   in this document, readers are encouraged to review notices filed with
   the IETF and stored at:

      http://www.ietf.org/ipr.html













Armitage, et al.             Informational                      [Page 8]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


References

   [1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding
       PHB", RFC 2598, June 1999.

   [2] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le
       Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
       Kalmanek, C., Ramakrishnan, K. and D. Stiliadis, "An Expedited
       Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

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

   [4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
       the Differentiated Services Field (DS Field) in the IPv4 and IPv6
       Headers", RFC 2474, December 1998.

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































Armitage, et al.             Informational                      [Page 9]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


Authors (volunteer EF Design Team members)

   Grenville Armitage
   Center for Advanced Internet Architectures
   Swinburne University of Technology,
   Melbourne, Australia
   EMail: [e-mail]

   Brian E. Carpenter (team observer, WG co-chair)
   IBM Zurich Research Laboratory
   Saeumerstrasse 4
   8803 Rueschlikon
   Switzerland
   EMail: [e-mail]

   Alessio Casati
   Lucent Technologies
   Swindon, WI  SN5 7DJ  United Kingdom
   EMail: [e-mail]

   Jon Crowcroft
   Marconi Professor of Communications Systems
   University of Cambridge
   Computer Laboratory
   William Gates Building
   J J Thomson Avenue
   Cambridge
   CB3 0FD
   Phone: [phone]
   EMail: [e-mail]

   Joel M. Halpern
   P. O. Box 6049
   Leesburg, VA 20178
   Phone: [phone]
   EMail: [e-mail]

   Brijesh Kumar
   Corona Networks Inc.,
   630 Alder Drive,
   Milpitas, CA 95035
   EMail: [e-mail]

   John Schnizlein
   Cisco Systems
   9123 Loughran Road
   Fort Washington, MD 20744
   EMail: [e-mail]



Armitage, et al.             Informational                     [Page 10]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


Full Copyright Statement

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



















Armitage, et al.             Informational                     [Page 11]