Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7179 Huawei
Updates: 6325 A. Ghanwani
Category: Standards Track Dell
ISSN: 2070-1721 V. Manral
Ionos Corp.
Y. Li
Huawei
C. Bestler
Nexenta Systems
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7179 Huawei
Updates: 6325 A. Ghanwani
Category: Standards Track Dell
ISSN: 2070-1721 V. Manral
Ionos Corp.
Y. Li
Huawei
C. Bestler
Nexenta Systems
May 2014
Transparent Interconnection of Lots of Links (TRILL): Header Extension
大量链路的透明互连（TRILL）：报头扩展
Abstract
摘要
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.
IETF大量链路透明互连（TRILL）基本协议（RFC6325）规定了安全支持TRILL报头扩展的最小挂钩。本文档指定了提供附加标志位的初始扩展，并指定了其中的一些位。它更新了RFC6325。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7179.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7179.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. TRILL Header Extensions .........................................3
2.1. RBridge Extended Flag Handling Requirements ................5
2.2. No Critical Surprises ......................................5
2.3. Extended Header Flags ......................................6
2.3.1. Critical Summary Bits ...............................7
2.4. Conflict of Extensions .....................................8
3. Specific Extended Header Flags ..................................9
3.1. RBridge Channel Alert Extended Flags .......................9
4. Additions to IS-IS ..............................................9
5. IANA Considerations ............................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. TRILL Header Extensions .........................................3
2.1. RBridge Extended Flag Handling Requirements ................5
2.2. No Critical Surprises ......................................5
2.3. Extended Header Flags ......................................6
2.3.1. Critical Summary Bits ...............................7
2.4. Conflict of Extensions .....................................8
3. Specific Extended Header Flags ..................................9
3.1. RBridge Channel Alert Extended Flags .......................9
4. Additions to IS-IS ..............................................9
5. IANA Considerations ............................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
The base IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides a TRILL Header extension feature and describes minimal hooks to safely support header extensions. (This feature is called "options" in Section 3.8 of [RFC6325].) But, except for the first two bits, the TRILL base protocol document does not specify the structure of extensions to the TRILL Header nor the details of any particular extension.
基本IETF多链路透明互连（TRILL）协议[RFC6325]提供了TRILL报头扩展功能，并描述了安全支持报头扩展的最小挂钩。（此功能在[RFC6325]第3.8节中称为“选项”），但除前两位外，TRILL基本协议文件未规定TRILL标头扩展的结构或任何特定扩展的详细信息。
This document is consistent with [RFC6325] and provides further details. It specifies an initial extension word providing additional flag bits and specifies some of those bits. Additional extensions, including TLV-encoded options, may be specified in later documents, for example, [Options] and [Options2].
本文件与[RFC6325]一致，并提供了进一步的详细信息。它指定提供附加标志位的初始扩展字，并指定其中的一些位。其他扩展，包括TLV编码的选项，可以在以后的文档中指定，例如，[options]和[Options2]。
Section 2 below describes some general principles of TRILL Header extensions and an initial extension. Section 3 specifies a pair of flags in this initial extension.
下面的第2节描述了TRILL头扩展和初始扩展的一些一般原则。第3节指定了此初始扩展中的一对标志。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. Devices implementing the TRILL protocol are referred to as RBridges (Routing Bridges) or TRILL Switches.
[RFC6325]中定义的术语和首字母缩略词在此具有相同的含义。实现TRILL协议的设备称为RBridges（路由桥）或TRILL交换机。
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]中所述进行解释。
The base TRILL protocol includes a feature for extension of the TRILL Header (see [RFC6325], Sections 3.5 and 3.8). The 5-bit Op-Length header field gives the length of the extensions to the TRILL Header in units of 4 octets, which allows up to 124 octets of header extension. If Op-Length is zero, there are no header extensions present; else, the extension area follows immediately after the Ingress RBridge Nickname field of the TRILL Header. The first 32-bit word of the optional extensions area consists of an extended flags area and critical summary bits as specified in this document.
基本颤音协议包括一个用于扩展颤音头的功能（参见[RFC6325]，第3.5和3.8节）。5位Op Length标头字段以4个八位字节为单位给出TRILL标头的扩展长度，最多允许124个八位字节的标头扩展。如果Op长度为零，则不存在标头扩展；否则，扩展区域紧跟在TRILL报头的入口RBridge昵称字段之后。可选扩展区域的第一个32位字由扩展标志区域和本文档中指定的关键摘要位组成。
As described below, provision is made for
如下文所述，所列经费用于：
o hop-by-hop flags, which might affect any RBridge that receives a TRILL Data frame with such a flag set,
o 逐跳标志，这可能会影响任何接收带有此类标志集的颤音数据帧的RBridge，
o ingress-to-egress flags, which would only necessarily affect the RBridge(s) where a TRILL frame is decapsulated,
o 从入口到出口的标志，这只会影响到颤音帧被解除封装的RBridge，
o flags affecting an as-yet-unspecified class of RBridges, for example, border RBridges in a TRILL campus extended to support multi-level IS-IS (Intermediate System to Intermediate System) [MultiLevel], and
o 影响尚未指定的RBridge类的标志，例如，TRILL校园中的边界RBridge扩展为支持多级IS-IS（中间系统到中间系统）[多级]，以及
o both "critical" and "non-critical" flags.
o “关键”和“非关键”标志。
Any RBridge receiving a frame with a critical hop-by-hop extension that it does not implement MUST discard the frame because it is unsafe to process the frame without understanding such a critical extension.
任何接收到具有关键逐跳扩展（未实现）的帧的RBridge必须丢弃该帧，因为在不了解此类关键扩展的情况下处理该帧是不安全的。
Any egress RBridge receiving a frame with a critical ingress-to-egress extension it does not implement MUST drop the frame if it is a unicast frame (TRILL Header M bit = 0); if it is a multi-destination TRILL Data frame (M=1), then it MUST NOT be egressed at that RBridge, but the egress RBridge still forwards such a frame on the distribution tree.
如果是单播帧（TRILL报头M比特=0），则接收到具有其未实现的关键入口到出口扩展的帧的任何出口RBridge必须丢弃该帧；如果它是多目的地TRILL数据帧（M＝1），则它不能在该RBridge处被导出，但是该导出RBridge仍然在分发树上转发这样的帧。
Non-critical extensions can be safely ignored.
可以安全地忽略非关键扩展。
Any extended flag indicating a significant change in the structure or interpretation of later parts of the frame that, if the extended flag were ignored, could cause a failure of service or violation of security policy MUST be a critical extension. If such an extended flag affects any fields that transit RBridges will examine, it MUST be a hop-by-hop critical extended flag.
如果忽略扩展标志，则表明框架后期部分的结构或解释发生重大变化，可能导致服务失败或违反安全策略的任何扩展标志都必须是关键扩展。如果此扩展标志影响transit RBridges将检查的任何字段，则它必须是逐跳关键扩展标志。
Note: Most RBridge implementations are expected to be optimized for simple and common cases of frame forwarding and processing. Although the hard limit on the header extensions area length, the 32-bit alignment of the extension area, and the presence of critical extension summary bits, as described below, are intended to assist in the efficient hardware processing of frames with a TRILL Header extensions area, nevertheless the inclusion of extensions may cause frame processing using a "slow path" with inferior performance to "fast path" processing. Limited slow path throughput of such frames could cause some of them to be discarded.
注意：大多数RBridge实现预计将针对简单和常见的帧转发和处理情况进行优化。尽管如下所述，对报头扩展区域长度的硬限制、扩展区域的32位对齐以及关键扩展摘要位的存在旨在帮助对具有颤音报头扩展区域的帧进行有效的硬件处理，然而，包含扩展可能会导致使用“慢路径”的帧处理，其性能不如“快路径”处理。此类帧的有限慢路径吞吐量可能会导致其中一些帧被丢弃。
All RBridges MUST check whether there are any critical flags set that are necessarily applicable to their processing of the frame. To assist in this task, critical summary bits are provided that cover not only the extended flags specified herein but will cover any further extensions that may be specified in future documents, for example, [Options] and [Options2]. If an RBridge does not implement all critical flags in a TRILL Data frame, it MUST treat the frame as having an unimplemented critical extension as described in Section 2. A transit or egress RBridge may assume that the critical summary bits are correct.
所有RBridge必须检查是否有任何关键标志集必须适用于其帧处理。为了帮助完成这项任务，提供了关键摘要位，这些位不仅涵盖本文指定的扩展标志，还将涵盖未来文档中可能指定的任何进一步扩展，例如，[Options]和[Options2]。如果RBridge未在TRILL数据帧中实现所有关键标志，则必须将该帧视为具有未实现的关键扩展，如第2节所述。传输或出口RBridge可以假设关键汇总位是正确的。
In addition, a transit RBridge:
此外，交通桥：
o MAY set or clear hop-by-hop flags as specified for such flags;
o 可设置或清除为此类标志指定的逐跳标志；
o MUST adjust the length of the extensions area, including changing Op-Length in the TRILL Header, as appropriate if it adds or removes the extended header flags word;
o 必须调整扩展区域的长度，包括更改颤音标题中的Op长度，如果添加或删除扩展标题标志，则视情况而定；
o MUST, if it adds the word of extended header flags or changes any critical flags, correctly set the critical summary bits in the extended header flags word;
o 如果它添加了扩展头标志的字或更改了任何关键标志，则必须正确设置扩展头标志字中的关键摘要位；
o MUST NOT remove the extended header flags word unless it is all zero (either on arrival or after permitted modifications); and
o 不得删除扩展标题标志字，除非其全部为零（到达时或经过允许的修改）；和
o MUST NOT set or clear ingress-to-egress or reserved extended header flags except as specifically permitted in the specification of such flags.
o 不得设置或清除入口到出口或保留扩展报头标志，除非此类标志的规范中明确允许。
RBridges advertise the extended header flags they support in IS-IS PDUs (Protocol Data Units) [RFC7176]. Unless an RBridge advertises support for a critical extended header flag, it will not normally receive frames with that flag set. An RBridge is not required to support any extensions.
RBRIGE公布其在IS-IS PDU（协议数据单元）[RFC7176]中支持的扩展头标志。除非RBridge播发对关键扩展头标志的支持，否则它通常不会接收设置了该标志的帧。RBridge不需要支持任何扩展。
An RBridge SHOULD NOT set a critical extended flag in a frame unless,
RBridge不应在帧中设置关键扩展标志，除非，
o for a critical hop-by-hop extended header flag, it has determined that the next hop RBridge or RBridges that will accept the frame support that flag,
o 对于关键逐跳扩展标头标志，已确定将接受帧的下一跳RBridge或RBridge支持该标志，
o for a critical ingress-to-egress extended header flag, it has determined that the RBridge or RBridges that will egress the frame support that flag, or
o 对于从关键入口到出口的扩展报头标志，它已确定将从帧出口的RBridge或RBridge支持该标志，或
o for a critical reserved extended header flag, it may set such a flag only if it understands which RBridges it is applicable to and has determined that those RBridges that will accept the frame support that flag.
o 对于关键保留扩展报头标志，仅当其了解其适用于哪些RBridge并且已确定将接受帧的RBridge支持该标志时，才可设置该标志。
"SHOULD NOT" is specified above since there may be cases where it is acceptable for those frames, particularly for the multi-destination case, to be discarded or not egressed by any RBridges that do not implement the extended flag.
上面指定了“不应该”，因为可能存在这样的情况，即不实现扩展标志的任何rbridge可以丢弃或不退出这些帧，特别是对于多目的地情况。
If any extensions are present in a TRILL Header, as indicated by a non-zero Op-Length field, the first 32 bits of the extensions area consist of extended header flags, as described below. The remainder of the extensions area, if any, after the initial 32 bits may be specified in later documents, for example, [Options] and [Options2].
如果TRILL报头中存在任何扩展，如非零运算长度字段所示，则扩展区域的前32位由扩展报头标志组成，如下所述。初始32位之后的扩展区域的剩余部分（如果有）可以在以后的文档中指定，例如，[Options]和[Options2]。
Any RBridge adding an extensions area to a TRILL Header must set the first 32 bits to zero except when permitted or required to set one or more of those bits as specified. For TRILL Data frames with extensions present, any transit RBridge that does not discard the frame MUST transparently copy the extended flags word, except for modifications permitted by an extension implemented by that RBridge.
任何向TRILL报头添加扩展区域的RBridge必须将前32位设置为零，除非允许或需要按照规定设置一个或多个这些位。对于存在扩展名的TRILL数据帧，任何未丢弃帧的transit RBridge必须透明地复制扩展标志字，但该RBridge实现的扩展名允许的修改除外。
The extended header flags word is illustrated below and the meanings of these bits is further described in the list following the figure.
扩展头标志字如下所示，这些位的含义在图后的列表中进一步描述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension |
| possibly including TLV extensions ...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension |
| possibly including TLV extensions ...
(The first two critical summary bits are as specified in [RFC6325]. In this document, an "S", for Summary, has been added at the end of their acronyms. A third critical summary bit is also specified herein and its acronym also ends with an "S" for consistency.)
（前两个关键摘要位如[RFC6325]所述。在本文件中，在其首字母缩略词的末尾添加了一个“S”作为摘要。第三个关键摘要位也在本文件中指定，其首字母缩略词也以“S”结尾以保持一致。）
Bits Description
--------------------
Bits Description
--------------------
0-2 Crit.: Critical summary bits. 0 CHbHS: Critical Hop-by-Hop extension(s) are present. 1 CItES: Critical Ingress-to-Egress extension(s) are present. 2 CRSVS: Critical Reserved extension(s) are present.
0-2临界值：临界汇总位。0个CHBH：存在关键逐跳扩展。1：存在从入口到出口的关键扩展。2个CRSV：存在关键保留扩展。
3-7 CHbH: Critical Hop-by-Hop extended flag bits. 8-13 NCHbH: Non-critical Hop-by-Hop extended flag bits.
3-7 CHbH：关键逐跳扩展标志位。8-13 NCHbH：非关键逐跳扩展标志位。
14-16 CRSV: Critical Reserved extended flag bits. 17-20 NCRSV: Non-critical Reserved extended flag bits.
14-16 CRSV：关键保留扩展标志位。17-20 NCRSV：非关键保留扩展标志位。
21-26 CItE: Critical Ingress-to-Egress extended flag bits. 27-31 NCItE: Non-critical Ingress-to-Egress extended flag bits.
21-26引用：从关键入口到出口扩展标志位。27-31 NCItE：非关键入口到出口扩展标志位。
The top three bits of the extended header flags area, bits 0, 1, and 2 above, are called the critical summary bits. They summarize the presence of critical extensions as follows:
扩展头标志区域的前三位，即上面的位0、1和2，称为关键摘要位。它们将关键扩展的存在总结如下：
CHbHS: If the CHbHS (Critical Hop-by-Hop Summary) bit is one, one or more critical hop-by-hop extensions are present. These might be critical hop-by-hop extended header flags or critical hop-by-hop extensions after the first word in the extensions area. Transit RBridges that do not support all of the critical hop-by-hop extensions present, for example, an RBridge that supported no critical hop-by-hop extensions, MUST drop the frame. If the CHbHS bit is zero, the frame is safe, from the point of view of extensions processing, for a transit RBridge to forward, regardless of what extensions that RBridge does or does not support.
CHbHS：如果CHbHS（关键逐跳摘要）位为1，则存在一个或多个关键逐跳扩展。这些可能是关键逐跳扩展头标志或扩展区域中第一个单词后的关键逐跳扩展。不支持所有关键逐跳扩展（例如，不支持关键逐跳扩展的RBridge）的传输RBridge必须丢弃帧。如果CHbHS位为零，则从扩展处理的角度来看，帧对于传输RBridge是安全的，无论RBridge支持或不支持什么扩展。
CItES: If the CItES (Critical Ingress-to-Egress Summary) bit is a one, one or more critical ingress-to-egress extensions are present. These might be critical ingress-to-egress extended header flags or critical ingress-to-egress extensions after the first word in the extensions area. If the CItES bit is zero, no such extensions are present. If either CHbHS or CItES is non-zero, egress RBridges that do not support all critical extensions present, for example, an RBridge that supports no critical extensions, MUST drop the frame. If both CHbHS and CItES are zero, the frame is safe, from the point of view of extensions, for an egress RBridge to process, regardless of what extensions that RBridge does or does not support.
CItES：如果CItES（关键入口到出口摘要）位为1，则存在一个或多个关键入口到出口扩展。这些可能是严重的入口到出口扩展头标志，或者在扩展区域中的第一个字之后是严重的入口到出口扩展。如果CItES位为零，则不存在此类扩展。如果CHbHS或CItES为非零，则不支持所有关键扩展的出口RBridge（例如，不支持关键扩展的RBridge）必须丢弃帧。如果CHbHS和CItES均为零，则无论RBridge支持或不支持哪些扩展，从扩展的角度来看，框架对于出口RBridge来说是安全的。
CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or more critical extensions are present that are reserved to apply to a class of RBridges to be specified in the future, for example, border RBridges in a TRILL campus extended to support multi-level IS-IS. This class will be a subset of transit RBridges. RBridges in this class MUST drop frames with the CRSVS bit set unless they implement all critical hop-by-hop and all critical reserved extensions present in the frame.
CRSVS：如果CRSVS（关键保留摘要）位为1，则存在一个或多个关键扩展，这些扩展保留为应用于将来指定的RBridge类，例如，TRILL园区中的边界RBridge扩展为支持多级is-is。该类将是运输桥的一个子集。此类中的RBridge必须丢弃设置了CRSVS位的帧，除非它们实现了帧中存在的所有关键逐跳和所有关键保留扩展。
The critical summary bits enable simple and efficient processing of TRILL Data frames by egress RBridges that support no critical extensions, by transit RBridges that support no critical hop-by-hop extensions, and by RBridges in the reserved class that support no critical hop-by-hop or reserved extensions. Such RBridges need only check whether Op-Length is non-zero and, if it is, check the top one, two, or three bits just after the fixed portion of the TRILL Header. Based on those three bits, such RBridges can decide whether to discard or forward/process the frame.
通过不支持关键扩展的出口RBridge、不支持关键逐跳扩展的中转RBridge以及不支持关键逐跳或保留扩展的保留类RBridge，关键摘要位能够简单高效地处理颤音数据帧。这样的RBridges只需检查Op Length是否为非零，如果为非零，则检查TRILL报头固定部分之后的顶部1、2或3位。基于这三个比特，这些rbridge可以决定是丢弃还是转发/处理帧。
Defining TRILL extensions including extended header flags that conflict with each other would be undesirable. Should conflicting extensions appear in the same packet, the results would be unpredictable if different implementations processed them in different orders. While rules could be defined to specify how to predictably process conflicting extensions, such rules would also limit implementation flexibility and could impose substantial processing burdens.
定义包含彼此冲突的扩展头标志的TRILL扩展是不可取的。如果冲突的扩展出现在同一个数据包中，那么如果不同的实现以不同的顺序处理它们，结果将是不可预测的。虽然可以定义规则来指定如何以可预测的方式处理冲突的扩展，但此类规则也会限制实现灵活性，并可能造成巨大的处理负担。
Conflicting extensions SHOULD NOT be defined, but if they are, careful thought should be given as to whether and how to specify the handling of conflicting extensions.
不应定义冲突扩展，但如果定义了冲突扩展，则应仔细考虑是否以及如何指定冲突扩展的处理。
The table below shows the state of TRILL Header extended flag assignments. See Section 5 for IANA Considerations.
下表显示了TRILL标头扩展标志分配的状态。IANA注意事项见第5节。
Bits Purpose Section
----------------------------------------------------------------
0-2 Critical Summary Bits 2.3.1
3-6 available critical hop-by-hop flags
7 Critical Channel Alert flag 3.1
8 Non-critical Channel Alert flag 3.1
9-13 available non-critical hop-by-hop flags
14-16 available critical reserved flags
17-20 available non-critical reserved flags
21-26 available critical ingress-to-egress flags
27-31 available non-critical ingress-to-egress flags
Bits Purpose Section
----------------------------------------------------------------
0-2 Critical Summary Bits 2.3.1
3-6 available critical hop-by-hop flags
7 Critical Channel Alert flag 3.1
8 Non-critical Channel Alert flag 3.1
9-13 available non-critical hop-by-hop flags
14-16 available critical reserved flags
17-20 available non-critical reserved flags
21-26 available critical ingress-to-egress flags
27-31 available non-critical ingress-to-egress flags
Table 1: Extended Header Flags Area
表1：扩展头标志区域
The RBridge Channel Alert extended header flags indicate that the frame is an RBridge Channel frame [RFC7178] that requests processing at each hop.
RBridge Channel Alert extended header标志表示该帧是在每个跃点请求处理的RBridge Channel帧[RFC7178]。
If the Critical Channel Alert flag (bit 7) is a one and the RBridge does not implement the RBridge Channel feature or the particular RBridge Channel protocol involved [RFC7178] or the frame does not actually appear to be an RBridge Channel message, then the frame is discarded. This permits implementation, for example, of a channel message requiring strict source routing or the like, with assurance that it will be discarded rather than deviate from the directed path.
如果关键信道警报标志（位7）为1，且RBridge未实现RBridge信道功能或涉及的特定RBridge信道协议[RFC7178]，或者该帧实际上似乎不是RBridge信道消息，则丢弃该帧。这允许例如实现需要严格的源路由等的信道消息，并保证其将被丢弃而不是偏离定向路径。
If the frame is not discarded as described above, then the presence of either the Critical or Non-critical Channel Alert flag alerts transit RBridges to the presence of an RBridge Channel message [RFC7178] that may require special handling. The non-critical alert flag supports, for example, an RBridge Channel protocol message including a "record route" function where not recording transit RBridges that do not support this function is acceptable.
如果帧没有如上所述被丢弃，则关键或非关键信道警报标志的存在会向RBridge发出警报，提示RBridge存在可能需要特殊处理的RBridge信道消息[RFC7178]。例如，非严重警报标志支持包括“记录路由”功能的RBridge信道协议消息，其中不记录不支持此功能的传输RBridge是可接受的。
RBridges use IS-IS Link State PDUs (LSPs) to inform other RBridges which extended header flags they support. The IS-IS PDU(s), TLV(s), or sub-TLV(s) used to encode and advertise this information are specified in a separate document [RFC7176].
RBridge使用IS-IS链路状态PDU（LSP）通知其他RBridge它们支持哪些扩展头标志。用于编码和公布此信息的IS-IS PDU、TLV或子TLV在单独的文档[RFC7176]中指定。
IANA has created a "TRILL Extended Header Flags" subregistry within the TRILL Parameters registry. The "TRILL Extended Header Flags" subregistry is initially populated as specified in Table 1 in Section 3. References in that table to sections of this document have been replaced in the IANA subregistry by references to this document as an RFC.
IANA在TRILL参数注册表中创建了一个“TRILL扩展头标志”子区域。“TRILL Extended Header Flags”子区域最初按照第3节表1中的规定填充。该表中对本文件章节的引用已在IANA分区域中被本文件作为RFC的引用所取代。
New TRILL extended header flags are allocated by IETF Review [RFC5226].
IETF Review[RFC5226]分配了新的TRILL扩展头标志。
To indicate support of extended header flags, IANA has assigned the following bits in the TRILL-VER and PORT-TRILL-VER Sub-TLV Capability Flag registries created by [RFC7176]:
为了表示支持扩展报头标志，IANA在[RFC7176]创建的TRILL-VER和PORT-TRILL-VER子TLV能力标志注册表中分配了以下位：
o Bits 3-13 of the PORT-TRILL-VER Sub-TLV Capability Flags have been assigned to indicate support of TRILL hop-by-hop extended header flags 3-13.
o 已分配PORT-TRILL-VER子TLV能力标志的位3-13，以指示对TRILL逐跳扩展报头标志3-13的支持。
o Bits 14-31 of the TRILL-VER Sub-TLV Capability Flags have been assigned to indicate support of TRILL extended header flags 14-31.
o TRILL-VER子TLV能力标志的位14-31已分配，以指示对TRILL扩展头标志14-31的支持。
For general TRILL protocol security considerations, see [RFC6325].
有关TRILL协议的一般安全注意事项，请参阅[RFC6325]。
For security considerations related to extended header flags, see the document where the flag is specified.
有关扩展头标志的安全注意事项，请参阅指定标志的文档。
It is important that the critical summary bits in the extended header flags word be set properly. If set when critical extensions of the appropriate category are not present, frames may be unnecessarily discarded. If not set when critical extensions are present, frames may be mishandled or corrupted, and intended security policies may be violated.
正确设置扩展头标志字中的关键摘要位非常重要。如果在不存在适当类别的关键扩展时设置，则可能会不必要地丢弃帧。如果在存在关键扩展时未设置，则可能会错误处理或损坏帧，并且可能违反预期的安全策略。
The RBridge Channel Alert extended header flags have the following security considerations. Implementations should keep in mind that they might be erroneously set in a frame. If either RBridge Channel Alert flag is found set in a frame that is not an RBridge Channel message [RFC7178], the flag MAY be cleared and should have no effect except, possibly, delaying processing of the frame. If either RBridge Channel Alert flag is erroneously omitted from a frame, desired per-hop processing for the frame may not occur.
RBridge Channel Alert extended header标志具有以下安全注意事项。实现应该记住，它们可能被错误地设置在一个框架中。如果发现在非RBRIGE信道消息[RFC7178]的帧中设置了任一RBRIGE信道警报标志，则该标志可能会被清除，并且除了可能延迟帧的处理之外，该标志不会产生任何影响。如果从帧中错误地省略了任一RBridge信道警报标志，则可能不会对该帧进行所需的每跳处理。
The following, listed in alphabetic order, are thanked for their valuable contributions: Ben Campbell, Adrian Farrel, Barry Leiba, and Thomas Narten.
以下按字母顺序排列的人感谢他们的宝贵贡献：本·坎贝尔、阿德里安·法雷尔、巴里·莱巴和托马斯·纳滕。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，2014年5月。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月。
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[多层次]帕尔曼，R.，东湖第三大道，加瓦尼，A.，和H.翟，“灵活多层次颤音（大量链接的透明互连）”，正在进行的工作，2014年1月。
[Options] Eastlake 3rd, D., Ghanwani, A., Manral, V., and C. Bestler, "RBridges: Further TRILL Header Extensions", Work in Progress, June 2012.
[选项]Eastlake 3rd，D.，Ghanwani，A.，Manral，V.，和C.Bestler，“RBridges:进一步的颤音标题扩展”，正在进行的工作，2012年6月。
[Options2] Eastlake 3rd, D., "RBridges: More Proposed TRILL Header Options", Work in Progress, October 2011.
[Options2]Eastlake 3rd，D.，“RBridges：更多建议的颤音标题选项”，正在进行的工作，2011年10月。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德海狸街155号唐纳德东湖第三华为研发有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450美国加利福尼亚州圣克拉拉大美洲公园路95054
EMail: anoop@alumni.duke.edu
EMail: anoop@alumni.duke.edu
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
Vishwas Manral Ionios公司，美国加利福尼亚州圣何塞摩尔帕克大道4100号，邮编95117
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号宜州利华为技术有限公司210012
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Caitlin Bestler Nexenta Systems 455 El Camino Real Santa Clara, CA 95050 USA
Caitlin Bestler Nexenta Systems 455 El Camino Real Santa Clara，加利福尼亚州，美国95050
EMail: caitlin.bestler@nexenta.com
EMail: caitlin.bestler@nexenta.com