Network Working Group S. Brim
Request for Comments: 2836 B. Carpenter
Category: Standards Track F. Le Faucheur
May 2000
Network Working Group S. Brim
Request for Comments: 2836 B. Carpenter
Category: Standards Track F. Le Faucheur
May 2000
Per Hop Behavior Identification Codes
每跳行为识别码
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Table of Contents:
目录：
1. Introduction................................................. 1
1.1. Usage Scenarios............................................ 2
2. Encoding..................................................... 3
3. IANA Considerations.......................................... 4
4. Security considerations...................................... 4
References...................................................... 4
Authors' Addresses.............................................. 5
Intellectual Property........................................... 6
Full Copyright Statement........................................ 7
1. Introduction................................................. 1
1.1. Usage Scenarios............................................ 2
2. Encoding..................................................... 3
3. IANA Considerations.......................................... 4
4. Security considerations...................................... 4
References...................................................... 4
Authors' Addresses.............................................. 5
Intellectual Property........................................... 6
Full Copyright Statement........................................ 7
Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings.
区分服务[RFC 2474，RFC 2475]引入了每跳行为（PHB）的概念，定义了属于特定行为聚合的流量在单个网络节点上的处理方式。在IP分组报头中，phb没有这样指示；而是使用区分服务代码点（DSCP）值。只有64个可能的DSCP值，但对PHB的数量没有这样的限制。在给定的网络域中，DSCP值和PHB之间存在本地定义的映射。标准化PHB建议使用DSCP映射，但网络运营商可以选择其他映射。
In some cases it is necessary or desirable to identify a particular PHB in a protocol message, such as a message negotiating bandwidth management or path selection, especially when such messages pass between management domains. Examples where work is in progress include communication between bandwidth brokers, and MPLS support of diffserv.
在某些情况下，有必要或希望识别协议消息中的特定PHB，例如协商带宽管理或路径选择的消息，尤其是当此类消息在管理域之间传递时。正在进行工作的示例包括带宽代理之间的通信，以及区分服务的MPLS支持。
In certain cases, what needs to be identified is not an individual PHB, but a set of PHBs. One example is a set of PHBs that must follow the same physical path to prevent re-ordering. An instance of this is the set of three PHBs belonging to a single Assured Forwarding class, such as the PHBs AF11, AF12 and AF13 [RFC 2597].
在某些情况下，需要确定的不是单个PHB，而是一组PHB。例如，一组PHB必须遵循相同的物理路径，以防止重新排序。这方面的一个实例是属于单个保证转发类的三个phb的集合，例如phb AF11、AF12和AF13[RFC 2597]。
This document defines a binary encoding to uniquely identify PHBs and/or sets of PHBs in protocol messages. This encoding MUST be used when such identification is required.
本文档定义了二进制编码，以唯一标识协议消息中的PHB和/或PHB集。当需要此类标识时，必须使用此编码。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Diffserv services are expected to be supported over various underlying technologies which we broadly refer to as "link layers" for the purpose of this discussion. For the transport of IP packets, some of these link layers make use of connections or logical connections where the forwarding behavior supported by each link layer device is a property of the connection. In particular, within the link layer domain, each link layer node will schedule traffic depending on which connection the traffic is transported in. Examples of such "link layers" include ATM and MPLS.
Diffserv服务预计将通过各种底层技术得到支持，在本次讨论中，我们广泛地称之为“链路层”。对于IP数据包的传输，其中一些链路层使用连接或逻辑连接，其中每个链路层设备支持的转发行为是连接的属性。特别地，在链路层域内，每个链路层节点将根据在哪个连接中传输流量来调度流量。这种“链路层”的示例包括ATM和MPLS。
For efficient support of diffserv over these link layers, one model is for different Behavior Aggregates (BAs) (or sets of Behavior Aggregates) to be transported over different connections so that they are granted different (and appropriate) forwarding behaviors inside the link layer cloud. When those connections are dynamically established for the transport of diffserv traffic, it is very useful to communicate at connection establishment time what forwarding behavior(s) is(are) to be granted to each connection by the link layer device so that the BAs transported experience consistent forwarding behavior inside the link layer cloud. This can be achieved by including in the connection establishment signaling messages the encoding of the corresponding PHB, or set of PHBs, as defined in this document. Details on proposed usage of PHB encodings by some MPLS label distribution protocols (RSVP and LDP) for support of Diff-Serv over MPLS, can be found in [MPLS-DS].
为了在这些链路层上有效支持diffserv，一种模型是通过不同的连接传输不同的行为聚合（BAs）（或行为聚合集集），以便在链路层云中授予它们不同（且适当）的转发行为。当为传输区分服务流量而动态建立这些连接时，在连接建立时通信链路层设备将授予每个连接的转发行为是非常有用的，以便BAs传输在链路层云中体验一致的转发行为。这可以通过在连接建立信令消息中包括本文档中定义的相应PHB或PHB组的编码来实现。关于一些MPLS标签分发协议（RSVP和LDP）提议使用PHB编码来支持MPLS上的区分服务的详细信息，请参见[MPLS-DS]。
In another approach, the ATM Forum has a requirement to indicate desired IP QOS treatments in ATM signaling, so that ATM switches can be just as supportive of the desired service as are IP forwarders. To do so the Forum is defining a new VC call setup information element is which will carry PHB identification codes (although will be generalized to do more if needed).
在另一种方法中，ATM论坛要求在ATM信令中指示所需的IP QOS处理，以便ATM交换机可以像IP转发器一样支持所需的服务。为了做到这一点，论坛正在定义一个新的VC呼叫设置信息元素is，该元素将携带PHB识别码（尽管如果需要，将被推广到做更多的事情）。
PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field.
PHB和PHB集编码在无符号16位二进制字段中。
The 16 bit field is arranged as follows:
16位字段的排列如下：
Case 1: PHBs defined by standards action, as per [RFC 2474].
案例1：根据[RFC 2474]由标准行动定义的PHB。
The encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping.
单个PHB的编码是该PHB的建议DSCP值，在16位字段中左对齐，位6到15设置为零。请注意，即使有问题的网络选择了不同的映射，也必须使用建议的DSCP值。
The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.)
一组PHB的编码是集合中各种PHB的编码集合中数值最小的，位14设置为1。（因此，对于AF1x PHB，编码是AF11 PHB的编码，位14设置为1。）
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSCP | 0 0 0 0 0 0 0 0 X 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSCP | 0 0 0 0 0 0 0 0 X 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Case 2: PHBs not defined by standards action, i.e. experimental or local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 bit PHB identification code, assigned by the IANA, is placed left-justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
案例2：标准行动未定义PHB，即[RFC 2474]允许的实验性或本地使用PHB。在这种情况下，IANA分配的任意12位PHB识别码在16位字段中左对齐。对于单个PHB，位15设置为1，对于一组PHB，位14为0或1。第12位和第13位为零。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PHB id code | 0 0 X 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PHB id code | 0 0 X 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future.
位12和13保留用于PHB标识码的扩展，或用于将来某个时候的其他用途。
IANA is requested to create a new assignment registry for "Per-Hop Behavior Identification Codes", initially allowing values in the range 0 to 4095 decimal.
IANA被要求为“每跳行为识别码”创建一个新的分配注册表，最初允许0到4095十进制范围内的值。
Assignment of values in this field require:
分配此字段中的值需要：
-the identity of the assignee -a brief description of the new PHB, with enough detail to distinguish it from existing standardized and non-standardized PHBs. In the case of a set of PHBs, this description should cover all PHBs in the set. -a reference to a stable document describing the PHB in detail.
-受让人身份——新PHB的简要说明，详细程度足以将其与现有标准化和非标准化PHB区分开来。对于一组PHB，此说明应涵盖该组中的所有PHB-对详细描述PHB的稳定文件的引用。
During the first year of existence of this registry, IANA is requested to refer all requests to the IETF diffserv WG for review. Subsequently, requests should be reviewed by the IETF Transport Area Directors or by an expert that they designate.
在该登记册存在的第一年内，IANA被要求将所有请求提交给IETF diffserv工作组审查。随后，IETF运输区域主管或其指定的专家应对请求进行审查。
If the number of assignments begins to approach 4096, the Transport Area Directors should be alerted.
如果任务数量开始接近4096，应通知运输区域主管。
This encoding in itself raises no security issues. However, users of this encoding should consider that modifying a PHB identification code may constitute theft or denial of service, so protocols using this encoding must be adequately protected.
这种编码本身不会引起安全问题。然而，这种编码的用户应该考虑修改PHB识别码可能构成盗窃或拒绝服务，因此必须充分保护使用该编码的协议。
References
工具书类
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2474] 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.
[RFC 2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC 2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC 2597]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保付PHB集团”，RFC 2597，1999年6月。
[MPLS-DS] MPLS Support of Differentiated Services, Francois Le Faucheur, Liwen Wu, Bruce Davie, Shahram Davari, Pasi Vaananen, Ram Krishnan, Pierrick Cheval, Juha Heinanen, Work in Progress.
[MPLS-DS]MPLS对差异化服务的支持，Francois Le Faucheur、Liwen Wu、Bruce Davie、Shahram Davari、Pasi Vaananen、Ram Krishnan、Pierrick Cheval、Juha Heinanen，正在进行中。
Authors' Addresses
作者地址
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
斯科特W.布里姆美国纽约州伊萨卡Honness Lane 146号，邮编14850
EMail: sbrim@cisco.com
EMail: sbrim@cisco.com
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
Brian E.Carpenter IBM c/o iCAIR 150套房美国伊利诺伊州埃文斯顿枫叶大道1890号60201
EMail: brian@icair.org
EMail: brian@icair.org
Francois Le Faucheur Cisco Systems Petra B - Les Lucioles 291, rue Albert Caquot 06560 Valbonne France
Francois Le Faucheur Cisco Systems Petra B-Les Lucioles 291，Albert Caquot街06560号，法国瓦尔博内
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。