rfc3086.txt

RFC 的详细文档！

   "As much as possible as soon as possible".

   Packets of this PDB will not be completely starved and when resources
   are available (i.e., not required by packets from any other traffic
   aggregate), network elements should be configured to permit packets
   of this PDB to consume them.

   Network operators may bound the delay and loss rate for services
   constructed from this PDB given knowledge about their network, but
   such attributes are not part of the definition.

7.1.4 Parameters

   None.

7.1.5 Assumptions

   A properly functioning network, i.e., packets may be delivered from
   any ingress to any egress.

7.1.6 Example uses

   1. For the normal Internet traffic connection of an organization.

   2. For the "non-critical" Internet traffic of an organization.

   3. For standard domestic consumer connections

7.1.7 Environmental Concerns

   There are no environmental concerns specific to this PDB.

7.1.8 Security Considerations for BE PDB

   There are no specific security exposures for this PDB.  See the
   general security considerations in [RFC2474] and [RFC2475].





Nichols & Carpenter          Informational                     [Page 20]

RFC 3086             Diffserv per Domain Behaviors            April 2001


8 Guidelines for writing PDB specifications

   G1. Following the format given in this document, write a draft and
   submit it as an Internet Draft.  The document should have "diffserv"
   as some part of the name.  Either as an appendix to the draft, or in
   a separate document, provide details of deployment experience with
   measured results on a network of non-trivial size carrying realistic
   traffic and/or convincing simulation results (simulation of a range
   of modern traffic patterns and network topologies as applicable).
   The document should be brought to the attention of the diffserv WG
   mailing list, if active.

   G2. Initial discussion should focus primarily on the merits of the
   PDB, though comments and questions on the claimed attributes are
   reasonable.  This is in line with the Differentiated Services goal to
   put relevance before academic interest in the specification of PDBs.
   Academically interesting PDBs are encouraged, but would be more
   appropriate for technical publications and conferences, not for
   submission to the IETF.  (An "academically interesting" PDB might
   become a PDB of interest for deployment over time.)

   The implementation of the following guidelines varies, depending on
   whether there is an active diffserv working group or not.

   Active Diffserv Working Group path:

   G3. Once consensus has been reached on a version of a draft that it
   is a useful PDB and that the characteristics "appear" to be correct
   (i.e., not egregiously wrong) that version of the draft goes to a
   review panel the WG co-chairs set up to audit and report on the
   characteristics.  The review panel will be given a deadline for the
   review.  The exact timing of the deadline will be set on a case-by-
   case basis by the co-chairs to reflect the complexity of the task and
   other constraints (IETF meetings, major holidays) but is expected to
   be in the 4-8 week range.  During that time, the panel may correspond
   with the authors directly (cc'ing the WG co-chairs) to get
   clarifications.  This process should result in a revised draft and/or
   a report to the WG from the panel that either endorses or disputes
   the claimed characteristics.

   G4. If/when endorsed by the panel, that draft goes to WG last call.
   If not endorsed, the author(s) can give an itemized response to the
   panel's report and ask for a WG Last Call.








Nichols & Carpenter          Informational                     [Page 21]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   G5. If/when passes Last Call, goes to ADs for publication as a WG
   Informational RFC in our "PDB series".

   If no active Diffserv Working Group exists:

   G3. Following discussion on relevant mailing lists, the authors
   should revise the Internet Draft and contact the IESG for "Expert
   Review" as defined in section 2 of RFC 2434 [RFC2434].

   G4. Subsequent to the review, the IESG may recommend publication of
   the Draft as an RFC, request revisions, or decline to publish as an
   Informational RFC in the "PDB series".

9 Security Considerations

   The general security considerations of [RFC2474] and [RFC2475] apply
   to all PDBs.  Individual PDB definitions may require additional
   security considerations.

10 Acknowledgements

   The ideas in this document have been heavily influenced by the
   Diffserv WG and, in particular, by discussions with Van Jacobson,
   Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush,
   Frank Kastenholz, Aaron Falk, and a host of other people who should
   be acknowledged for their useful input but not be held accountable
   for our mangling of it.  Grenville Armitage coined "per domain
   behavior (PDB)" though some have suggested similar terms prior to
   that.  Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert
   reviewed the document and commented so as to improve its form.

References

   [RFC2474] 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.

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

   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2597, June 1999.

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





Nichols & Carpenter          Informational                     [Page 22]

RFC 3086             Diffserv per Domain Behaviors            April 2001


   [RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color
             Marker", RFC 2698, June 1999.

   [MODEL]   Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
             Informal Management Model for Diffserv Routers", Work in
             Progress.

   [MIB]     Baker, F., Chan, K. and A. Smith, "Management Information
             Base for the Differentiated Services Architecture", Work in
             Progress.

   [VW]      Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual
             Wire' Per-Domain Behavior", Work in Progress.

   [WCG]     Worldcom, "Internet Service Level Guarantee",
             http://www.worldcom.com/terms/service_level_guarantee/
             t_sla_terms.phtml

   [PSI]     PSINet, "Service Level Agreements",
             http://www.psinet.com/sla/

   [UU]      UUNET USA Web site, "Service Level Agreements",
             http://www.us.uu.net/support/sla/

   [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA
             Considerations", BCP 26, RFC 2434, October 1998.

Authors' Addresses

   Kathleen Nichols
   Packet Design, LLC
   2465 Latham Street, Third Floor
   Mountain View, CA 94040
   USA

   EMail: [e-mail]


   Brian Carpenter
   IBM
   c/o iCAIR
   Suite 150
   1890 Maple Avenue
   Evanston, IL 60201
   USA

   EMail: [e-mail]




Nichols & Carpenter          Informational                     [Page 23]

RFC 3086             Diffserv per Domain Behaviors            April 2001


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.



















Nichols & Carpenter          Informational                     [Page 24]