rfcrfc2597.txt

本程序为在linux下实现FTP传输文件的实现

高丢弃优先级     |  001110  |  010110  |  011110  |  100110  |
                      +----------+----------+----------+----------+
7．与其他PHB组的互操作
上述推荐的保证转发编码点的映射和本地用户空间以及在[Nichols]中推荐的类选择编码点互不干涉。因此类选择编码点选择的PHB可以和保证转发PHB组共存，并维持为它们定义的转发行为和关系。特别是，缺省的PHB编码点‘000000'仍然可以为传统的尽力而为流量所用。类似的，编码点‘11x000'可以为网络控制流量所用。
保证转发PHB组结合边界流量控制行为可以得到类选择器PHB包含的所有行为，这里的边界流量控制行为是限制每一个保证转发类的流量数（通常是不同的）不超过类所分配资源的百分比范围。在这种情况下，最好在一个区分范围域内使用部分或者所有类选择器编码点作为保证转发编码点的别名。
在同一个区分服务域中，除了类选择器PHB，任何其他的PHB组可以和保证转发PHB组共存。然而，任何保证转发PHB组的实现应该证明以下规则：
(a)如果存在其他PHB组，它们可以抢先占有特别分配给每一个保证转发PHB类的转发资源。这种抢先占有禁止在普通的网络运营中发生，但是在一些不寻常的状况下是可以的－例如， ‘11x000'编码点可以抢先占有保证转发的转发资源，在需要的时候，给网络控制流量一个意想不到的高优先级。
(b) “额外”的资源如何分配给保证转发PHB组和其他已实现的PHB组。例如，一旦给每一保证转发类分配最小的资源，任何剩余的资源可以在保证转发类和缺省PHB中平均分配。一个可选择的例子是，任何剩余资源可以被分配给转发额外的保证转发流量，只有当所有的保证转发要求都满足的时候，可以利用分配给缺省PHB的资源。
本文档没有说明任何保证转发PHB组和其他已实现的PHB组的任何特定关系：这只需要选择任何一个想要证明的关系。实现可能允许任一个或者所有可配置的关系。希望可以证明这种级别的配置灵活度对于许多网络管理员是有价值的。
8．安全因素
为了保护自身不受拒绝服务的攻击，一个提供方区分服务域应该将进入该域的流量限制在预定的特征描述内。同时，为了保护到客户区分服务域的链路不受拒绝服务攻击，提供方区分服务域应该允许客户方区分服务域指定链路资源如何分配给一个保证转发包。如果一种服务要求有保证转发编码点标记的流量，受到如源和目的地址这样的属性限制，网络的入口节点有责任检验这些属性的有效性。
其它安全考虑在[Blake]和[Nichols]已经涵盖。
9．知识产权
本文档中包含的部分或者全部规范的版权声明已经通知IETF（互联网工程任务小组）。想要知道更多信息，参考在线产权声明列表。
10．IANA考虑
如第6节所列，本文档分配12个编码点，它们属于[Nichols]中定义的编码空间的1号池。
附录：服务示例
例如，保证转发PHB组可以用来实现所谓的Olympic服务，这包括3个服务类：铜，银和金。包被分配到这3个类中，分配给金类的包比分配给银类的包经受的负载轻（因此具有更高的及时转发的概率）。在银和铜类之间存在一定的关系。如果需要，每一类中的包可以再分为低，中，高丢弃优先级，得到进一步分离。
在网络中的铜，银，金服务类可以被映射到保证转发类1，2，3。相似的，低，中，高丢弃优先级可以映射到保证转发丢弃优先级的1，2，3。
可以分配包的丢弃优先级，例如，使用漏桶流量策略器，它具有速率和大小两个参数，其中大小是承诺的突发大小和额外的突发大小两个突发值的和。如果桶中的令牌数比额外突发大小大，包被分配一个低丢弃优先级，如果桶中的令牌数比0大，但至多为额外突发大小，分配中丢弃优先级，如果桶为空，分配高丢弃优先级。可能需要对来自一个客户区分服务域具有高丢弃优先级流量的数目设置一个上限，以避免出现来自客户区分服务域无法投递的具有高丢弃优先级包的雪崩导致对来自其他域可投递的具有高丢弃优先级包的拒绝服务的情况。
另一种给包分配丢弃优先级的方法可以将一个Olympic服务类的用户流量限制在给定的峰值速率，并将它平均分配到每一种丢弃优先级。假设有高带宽微流的用户比低带宽微流用户预定一个更高的峰值速率，那么可以产生一个均衡的带宽服务，在拥塞发生的时候平均分配有效容量。
如果在每个区分服务节点到达这个类的最大到达速率是先验的，保证转发PHB组也可以利用额外提供的保证转发类来实现一种无时延和低时延服务。然而，必需的进入控制服务规范超出本文档范围。如果低丢失不太客观，那么通过对每个保证转发类的有效缓冲空间设置低的最大限制，无需额外规定，就可以实现低时延服务。
参考文献
[Blake]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. And W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[Bradner]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Clark]Clark, D. and Fang, W., Explicit Allocation of Best Effort Packet Delivery Service.  IEEE/ACM Transactions on Networking, Volume 6, Number 4, August 1998, pp. 362-373.
[Floyd]Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 1, Number 4, August 1993, pp. 397-413.
[Nichols] 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.
作者联系地址
Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland
EMail: [e-mail]

Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
EMail: [e-mail]

Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100,
Concord, MA  01742-2168
EMail: [e-mail]

John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA  02139
EMail: [e-mail]
完整版权声明
     Copyright (C) The Internet Society (1999).  版权所有.
本文档及其译文可以复制并对外提供。可以部分或全部编著、复制、出版、分发与其有关的评议、解释和有助于实施的派生著作，没有任何限制，但要求在复制文件和派生著作中包括上述版权警告及本节版权声明内容。但是，本文件的内容不允许做任何形式的修改，诸如删除版权警告或者关于互联网社团或者其他互联网组织的介绍，除非为了开发互联网标准或翻译成英语以外的其他语言的需要，即使在这种情况下，也仍然必须遵循互联网标准过程中确定的版权程序。
上述许可是永久性的，不会由互联网社团，它的继承者或转让者予以废除。
本文件及其提供的信息以“现状”为基础，互联网社团与IETF(因特网工程任务小组)否认所有的保证明示或暗示，包含但并不限于任何保证。所含信息的使用将不会侵犯具有特殊目的的商用性或者适用性的任何权利或隐含的保证。
致谢
RFC编者活动基金现在由互联网社团提供。
RFC2597——Assured Forwarding PHB Group                                 保证转发每一跳行为组

RFC文档中文翻译计划				1