Network Working Group D. Black
Request for Comments: 3140 S. Brim
Obsoletes: 2836 B. Carpenter
Category: Standards Track F. Le Faucheur
June 2001
Network Working Group D. Black
Request for Comments: 3140 S. Brim
Obsoletes: 2836 B. Carpenter
Category: Standards Track F. Le Faucheur
June 2001
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836.
本文档定义了一种16位编码机制，用于识别协议消息中的每跳区分服务行为。它取代了RFC 2836。
Table of Contents
目录
1. Introduction.................................................2
1.1. Usage Scenarios............................................2
2. Encoding.....................................................3
3. Signalling the Class Selector Codepoints.....................4
4. IANA Considerations..........................................5
5. Security Considerations......................................5
Changes from RFC 2836...........................................5
Acknowledgements................................................6
References......................................................6
Authors' Addresses..............................................6
Intellectual Property...........................................7
Full Copyright Statement........................................8
1. Introduction.................................................2
1.1. Usage Scenarios............................................2
2. Encoding.....................................................3
3. Signalling the Class Selector Codepoints.....................4
4. IANA Considerations..........................................5
5. Security Considerations......................................5
Changes from RFC 2836...........................................5
Acknowledgements................................................6
References......................................................6
Authors' Addresses..............................................6
Intellectual Property...........................................7
Full Copyright Statement........................................8
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集。当需要此类标识时，必须使用此编码。
This document replaces RFC 2836, which omitted considerations for the Class Selector codepoints.
本文档取代RFC 2836，后者省略了类选择器代码点的注意事项。
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标识码的扩展，或用于将来某个时候的其他用途。
In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC 2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID.
在这两种情况下，当使用单个PHBID识别一组PHB（即，位14设置为1）时，该组PHB必须构成PHB调度类（即，当同一微流中的不同PHB应用于同一微流中的流量时，使用该组PHB不得导致微流内流量重新排序）。AF1x PHB集合[RFC 2597]是PHB调度类的一个示例。可以通过使用多个PHBID来识别不构成PHB调度类的PHB集。
[RFC 2474] defines the eight DS codepoint values of the form 'xxx000' (where x may be '0' or '1') as the Class Selector Codepoints. Codepoint 000000 is the recommended DSCP value for the Default PHB, and hence the Case 1 PHBID constructed from that codepoint is used to signal the Default PHB (see Section 2 above).
[RFC 2474]将形式为“xxx000”（其中x可以是“0”或“1”）的八个DS码点值定义为类选择器码点。代码点000000是默认PHB的建议DSCP值，因此，由该代码点构造的案例1 PHBID用于向默认PHB发送信号（见上文第2节）。
For convenience and consistent operation with networks that employ IP Precedence [RFC 1812], the Case 1 format PHBIDs constructed from the other seven Class Selector Codepoints may also be used to signal PHBs. In each case, the PHB signaled by such a PHBID is the PHB to which the embedded class selector codepoint (or IP Precedence value that corresponds to it in non-diffserv domains) is mapped in the recipient's network. Note that different networks will employ different mappings; see Section 4 of [RFC 2474] for further discussion.
为了方便且与采用IP优先级的网络一致操作[RFC 1812]，从其他七个类选择器代码点构造的情况1格式PHBID也可用于向PHB发送信号。在每种情况下，由这种PHBID发出信号的PHB是接收方网络中嵌入的类选择器码点（或在非diffserv域中对应于它的IP优先级值）映射到的PHB。注意，不同的网络将使用不同的映射；有关进一步讨论，请参见[RFC 2474]第4节。
Any specified use of PHBIDs SHOULD allow the use of the eight Case 1 PHBIDs constructed from the Class Selector Codepoints.
PHBIDs的任何指定使用都应允许使用由类选择器代码点构造的八个案例1 PHBIDs。
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识别码可能构成盗窃或拒绝服务，因此必须充分保护使用该编码的协议。
Just signalling a PHBID SHOULD NOT be sufficient to grant the sender access to a PHB that it would otherwise not be able to use. In cases where this is an issue, receivers SHOULD treat received PHBIDs as requests for service, and use local policy to determine whether to grant or deny such requests.
仅发送PHBID信号不足以授予发送方访问PHB的权限，否则它将无法使用PHB。如果这是一个问题，接收方应将收到的PHBID视为服务请求，并使用当地政策确定是否批准或拒绝此类请求。
Changes from RFC 2836
RFC 2836的变更
[RFC 2836] did not consider the Class Selector code points, which are covered by section 3 of the present document. A clarification has been added at the end of section 2 for the case of PHB Scheduling Classes. The second paragraph of section 5 has been added.
[RFC 2836 ]没有考虑由本文档的第3部分所覆盖的类选择器代码点。第2节末尾添加了关于PHB调度类的澄清。增加了第5节的第二段。
Acknowledgements
致谢
Useful comments were made by members of the IETF Diffserv working group.
IETF Diffserv工作组的成员提出了有用的意见。
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月。
[RFC 2836] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[RFC 2836]Brim，S.，Carpenter，B.和F.Le Faucheur，“每跳行为识别码”，RFC 2836，2000年5月。
[MPLS-DS] Le Faucheur, F., et al., "MPLS Support of Differentiated Services", Work in Progress.
[MPLS-DS]Le Faucheur，F.等人，“MPLS对差异化服务的支持”，正在进行中。
Authors' Addresses
作者地址
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
David L.Black EMC公司马萨诸塞州霍普金顿南大街42号01748
EMail: black_david@emc.com
EMail: black_david@emc.com
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。