Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7175 Ionos Corp.
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei R&D USA
D. Ward
Cisco Systems
A. Banerjee
Cumulus Networks
May 2014
Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7175 Ionos Corp.
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei R&D USA
D. Ward
Cisco Systems
A. Banerjee
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
大量链路的透明互连（TRILL）：双向转发检测（BFD）支持
Abstract
摘要
This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.
本文件规定了双向转发检测（BFD）协议在路由桥（RBridge）校园中的使用，该协议基于RBridge信道对大量链路透明互连（TRILL）协议的扩展。
BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.
BFD是IP和MPLS网络中广泛部署的操作、管理和维护（OAM）机制，分别使用UDP和关联通道头（ACH）封装。本文档指定了TRILL上的BFD封装。
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/rfc7175.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7175.
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 ....................................................2
1.1. Terminology ................................................3
2. BFD over TRILL ..................................................3
2.1. Sessions and Initialization ................................4
3. TRILL BFD Control Protocol ......................................5
3.1. One-Hop TRILL BFD Control ..................................5
3.2. BFD Control Frame Processing ...............................5
4. TRILL BFD Echo Protocol .........................................6
4.1. BFD Echo Frame Processing ..................................6
5. Management and Operations Considerations ........................7
6. Default Authentication ..........................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................9
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. BFD over TRILL ..................................................3
2.1. Sessions and Initialization ................................4
3. TRILL BFD Control Protocol ......................................5
3.1. One-Hop TRILL BFD Control ..................................5
3.2. BFD Control Frame Processing ...............................5
4. TRILL BFD Echo Protocol .........................................6
4.1. BFD Echo Frame Processing ..................................6
5. Management and Operations Considerations ........................7
6. Default Authentication ..........................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................9
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10
Faster convergence is a critical feature of Transparent Interconnection of Lots of Links (TRILL) [RFC6325] networks. The TRILL IS-IS Hellos [RFC7177] [IS-IS] used between RBridges provide a basic neighbor and continuity check for TRILL links. However, failure detection by non-receipt of such Hellos is based on the Holding Time parameter that is commonly set to a value of tens of seconds and, in any case, has a minimum expressible value of one second.
更快的融合是多链路透明互连（TRILL）[RFC6325]网络的一个关键特性。在RBridge之间使用的TRILL IS-IS Hellos[RFC7177][IS-IS]为TRILL链接提供了基本的邻居和连续性检查。然而，不接收此类Hello的故障检测基于保持时间参数，该参数通常设置为数十秒的值，并且在任何情况下，具有1秒的最小可表达值。
Some applications, including Voice over IP, may wish, with high probability, to detect interruptions in continuity within a much shorter time period. In some cases, physical-layer failures can be detected very rapidly, but this is not always possible, such as when there is a failure between two bridges that are in turn between two RBridges. There are also many subtle failures possible at higher levels. For example, some forms of failure could affect unicast frames while still letting multicast frames through; since all TRILL IS-IS Hellos are multicast, such a failure cannot be detected with Hellos. Thus, a low-overhead method for frequently testing continuity for the TRILL Data between neighbor RBridges is necessary for some applications. The BFD protocol [RFC5880] provides a low-overhead method for the rapid detection of connectivity failures.
一些应用程序，包括IP语音，可能希望以很高的概率在更短的时间内检测到连续性中断。在某些情况下，可以非常快速地检测到物理层故障，但这并不总是可能的，例如，当两个桥之间的两个桥之间发生故障时，而这两个桥之间又发生故障。在更高的层次上，也有许多微妙的失败。例如，某些形式的故障可能会影响单播帧，同时仍允许多播帧通过；由于所有TRILL IS-IS HELLO都是多播的，因此无法使用HELLO检测到此类故障。因此，对于某些应用，需要一种低开销的方法来频繁测试相邻RBridge之间颤音数据的连续性。BFD协议[RFC5880]为快速检测连接故障提供了一种低开销方法。
BFD is a widely deployed OAM [RFC6291] mechanism in IP and MPLS networks, using UDP and ACH encapsulation, respectively. This document describes a TRILL encapsulation for BFD packets for networks that forward based on the TRILL Header.
BFD是IP和MPLS网络中广泛部署的OAM[RFC6291]机制，分别使用UDP和ACH封装。本文档描述了基于TRILL报头转发的网络BFD数据包的TRILL封装。
This document uses the acronyms defined in [RFC6325] along with the following:
本文件使用[RFC6325]中定义的首字母缩略词以及以下内容：
BFD: Bidirectional Forwarding Detection
双向转发检测
IP: Internet Protocol
互联网协议
IS-IS: Intermediate System to Intermediate System
IS-IS：中间系统至中间系统
MH: Multi-Hop
MH：多跳
PPP: Point-to-Point Protocol
点对点协议
OAM: Operations, Administration, and Maintenance
OAM：运营、管理和维护
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]中所述进行解释。
TRILL supports unicast neighbor BFD Echo and one-hop and multi-hop BFD Control, as specified below, over the RBridge Channel facility [RFC7178]. (Multi-destination BFD is a work in progress [MultiBFD].) BFD-over-TRILL support is similar to BFD-over-IP support [RFC5881], except where differences are explicitly mentioned.
TRILL支持单播邻居BFD回波和一跳和多跳BFD控制，如下所述，通过RBridge信道设施[RFC7178]。（多目标BFD是一项正在进行的工作[MultiBFD]）除明确提到差异外，BFD over TRILL支持与BFD over IP支持[RFC5881]类似。
Asynchronous and demand modes MUST be supported [RFC5880]. BFD over TRILL supports the Echo function; however, implementation of TRILL BFD Echo is optional, and it can only be used for single-hop sessions.
必须支持异步和按需模式[RFC5880]。颤音上的BFD支持回声功能；然而，TRILL BFD Echo的实现是可选的，它只能用于单跳会话。
The TRILL Header hop count in the BFD packets is sent out with the maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop count of a received session is checked [RFC5082]. For a single-hop session, if the hop count is less than 0x3F and the RBridge Channel Header MH flag is zero, the packet is discarded. For multi-hop sessions, the hop count check can be disabled if the MH flag is one.
BFD数据包中的TRILL报头跳数以最大值0x3F发送。为防止欺骗攻击，检查接收会话的颤音跳数[RFC5082]。对于单跳会话，如果跳数小于0x3F且RBridge通道头MH标志为零，则丢弃该数据包。对于多跳会话，如果MH标志为1，则可以禁用跳数检查。
As in BFD for IP, the format of the Echo Packet content is not defined.
在BFD for IP中，没有定义回送数据包内容的格式。
New RBridge Channel code points for BFD TRILL Control and BFD Echo packets are specified.
为BFD颤音控制和BFD回波数据包指定了新的RBridge通道代码点。
Authentication mechanisms as supported in BFD are also supported for BFD running over TRILL.
在TRILL上运行的BFD也支持BFD中支持的身份验证机制。
Within an RBridge campus, there will be no more than one TRILL BFD Control session from any RBridge RB1 to RBridge RB2 for each RB1 TRILL port. This BFD session must be bound to this interface. As such, both sides of a session MUST take the "Active" role (sending initial BFD Control packets with a zero value of Your Discriminator), and any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system and interface.
在RBridge园区内，对于每个RB1 TRILL端口，从任何RBridge RB1到RBridge RB2的TRILL BFD控制会话不超过一个。此BFD会话必须绑定到此接口。因此，会话的双方都必须扮演“主动”角色（发送初始BFD控制数据包时，鉴别器的值为零），并且来自远程计算机且鉴别器的值为零的任何BFD数据包必须与绑定到远程系统和接口的会话相关联。
Note that TRILL BFD provides OAM facilities for the TRILL data plane. This is above whatever protocol is in use on a particular link, such as a pseudowire [RFC7173], Ethernet [RFC6325], or PPP link [RFC6361]. Link-technology-specific OAM protocols may be used on a link between neighbor RBridges, for example, Continuity Fault Management [802.1Q] if the link is Ethernet. But such link-layer OAM (and coordination between it and OAM in the TRILL data-plane layer, such as TRILL BFD) is beyond the scope of this document.
请注意，TRILL BFD为TRILL数据平面提供了OAM功能。这高于特定链路上使用的任何协议，例如伪线[RFC7173]、以太网[RFC6325]或PPP链路[RFC6361]。特定于链路技术的OAM协议可用于相邻rbridge之间的链路，例如，如果链路是以太网，则连续性故障管理[802.1Q]。但是这种链路层OAM（以及它与TRILL数据平面层中的OAM之间的协调，如TRILL BFD）超出了本文的范围。
If lower-level mechanisms are in use, such as link aggregation [802.1AX], that present a single logical interface to TRILL IS-IS, then only a single TRILL BFD session can be established to any other RBridge over this logical interface. However, lower-layer OAM could be aware of and/or run separately on each of the components of an aggregation.
如果使用较低级别的机制，如链路聚合[802.1AX]，向TRILL IS-IS提供单个逻辑接口，则只能通过该逻辑接口向任何其他RBridge建立单个TRILL BFD会话。然而，较低层OAM可以知道和/或在聚合的每个组件上分别运行。
TRILL BFD Control frames are unicast TRILL RBridge Channel frames [RFC7178]. The RBridge Channel Protocol value is given in Section 8. The protocol-specific data associated with the TRILL BFD Control protocol is as shown in Section 4.1 of [RFC5880].
颤音BFD控制帧是单播颤音RBridge信道帧[RFC7178]。第8节给出了RBridge信道协议值。与TRILL BFD控制协议相关的协议特定数据如[RFC5880]第4.1节所示。
One-hop TRILL BFD Control is typically used to rapidly detect link and RBridge failures. TRILL BFD frames over one hop for such purposes SHOULD be sent with high priority; that is, the Inner.VLAN tag priority should be 7, they should be queued for transmission as maximum priority frames, and, if they are being sent on an Ethernet link where the output port is configured to include an Outer.VLAN tag, that tag should specify priority 7.
单跳颤音BFD控制通常用于快速检测链路和RBridge故障。在这种情况下，一跳以上的颤音BFD帧应以高优先级发送；也就是说，internal.VLAN标记优先级应为7，它们应作为最大优先级帧排队等待传输，并且，如果它们在输出端口配置为包含Outer.VLAN标记的以太网链路上发送，则该标记应指定优先级7。
For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL BFD Control frames to the other only if TRILL IS-IS has detected bidirectional connectivity; that is, the adjacency is in the 2-Way or Report state [RFC7177], and both RBridges indicate support of TRILL BFD is enabled. The BFD-Enabled TLV is used to indicate this as specified in [RFC6213].
对于相邻的RBridge RB1和RB2，仅当TRILL IS-IS检测到双向连接时，每个RBridge才向另一个发送一跳TRILL BFD控制帧；也就是说，邻接处于双向或报告状态[RFC7177]，两个RBridges都表示已启用对颤音BFD的支持。启用BFD的TLV用于指示[RFC6213]中规定的情况。
The following tests SHOULD be performed on received TRILL BFD Control frames before generic BFD processing.
在一般BFD处理之前，应对收到的颤音BFD控制帧执行以下测试。
o Is the M bit in the TRILL Header non-zero? If so, discard the frame. (Multi-destination BFD is a work in progress [MultiBFD].) Failure to perform this test would make a denial-of-service attack using bogus multi-destination BFD Control frames easier.
o 颤音标头中的M位是否为非零？如果是，则丢弃框架。（多目标BFD是一个正在进行的工作[MultiBFD]）执行此测试失败将使使用虚假多目标BFD控制帧的拒绝服务攻击变得更容易。
o If the Channel Header MH flag is zero, indicating one hop, test that the TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has already been decremented); if it is any other value, discard the frame. If the Channel Header MH flag is one, indicating multi-hop, test that the TRILL Header hop count received was not less than a configurable value that defaults to 0x30. If it is less, discard the frame. Failure to perform these tests would make it easier to spoof BFD Control frames. However, if forged BFD Control frames are a concern, then BFD Authentication [RFC5880] should be used.
o 如果信道头MH标志为零，表示一个跃点，则测试接收到的TRILL头跃点计数是否为0x3F（即，如果已经减小，则为0x3E）；如果它是任何其他值，则丢弃该帧。如果通道头MH标志为1，表示多跳，则测试接收到的颤音头跳计数是否不小于默认为0x30的可配置值。如果小于，则丢弃框架。如果不执行这些测试，就更容易欺骗BFD控制帧。但是，如果存在伪造BFD控制框架的问题，则应使用BFD认证[RFC5880]。
A TRILL BFD Echo frame is a unicast RBridge Channel frame, as specified in [RFC7178], which should be forwarded back by an immediate neighbor because both the ingress and egress nicknames are set to a nickname of the originating RBridge. Normal TRILL Data frame forwarding will cause the frame to be returned unless micro-loop suppression logic in the neighbor RBridge prohibits sending a frame back out the port on which it was received or the like. RBridges with such prohibitions cannot support BFD Echo. The TRILL OAM protocol number for BFD Echo is given in Section 8.
TRILL BFD回波帧是单播RBridge信道帧，如[RFC7178]中所述，它应该由直接邻居转发回去，因为入口和出口昵称都设置为发起RBridge的昵称。正常TRILL数据帧转发将导致帧返回，除非相邻RBridge中的微环抑制逻辑禁止将帧发送回接收它的端口或类似端口。具有此类禁令的RBridge无法支持BFD Echo。第8节给出了BFD回波的TRILL OAM协议编号。
TRILL BFD Echo frames SHOULD be sent on a link only if the following conditions are met. An Echo originating under other circumstances will consume bandwidth and CPU resources but is unlikely to be returned.
只有满足以下条件时，才能在链路上发送颤音BFD回波帧。在其他情况下发出的回波将消耗带宽和CPU资源，但不太可能返回。
- A TRILL BFD Control session has been established,
- 已建立TRILL BFD控制会话，
- TRILL BFD Echo support is indicated by the RBridge that would potentially respond to the BFD Echo,
- 颤音BFD回波支持由可能响应BFD回波的RBridge表示，
- The adjacency is in the Report state [RFC7177], and
- 邻接处于报告状态[RFC7177]，并且
- The TRILL BFD Echo originating RBridge wishes to make use of this optional feature.
- 颤音BFD回声源RBridge希望利用此可选功能。
Since the originating RBridge is the RBridge that will be processing a returned Echo frame, the entire TRILL BFD Echo protocol-specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is suggested that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back. For example, it could include its own System ID, the neighbor's System ID, a session identifier, and a sequence count as well as a Message Authentication Code.
由于原始RBridge是将处理返回的回波帧的RBridge，因此整个TRILL BFD回波协议特定数据区域被视为不透明，并由原始RBridge自行决定。然而，建议该数据包括发起RBridge可以认证返回的BFD回波帧并确认回显该帧的邻居的信息。例如，它可以包括自己的系统ID、邻居的系统ID、会话标识符、序列计数以及消息身份验证代码。
The following tests MUST be performed on returned TRILL BFD Echo frames before other processing. The RBridge Channel document [RFC7178] requires that the information in the TRILL Header be given to the BFD protocol.
在进行其他处理之前，必须对返回的颤音BFD回波帧执行以下测试。RBridge Channel文档[RFC7178]要求将TRILL头中的信息提供给BFD协议。
o Is the M bit in the TRILL Header non-zero? If so, discard the frame. (Multi-destination BFD is a work in progress [MultiBFD].)
o 颤音标头中的M位是否为非零？如果是，则丢弃框架。（多目标BFD是正在进行的工作[MultiBFD]。）
o The TRILL BFD Echo frame should have gone exactly two hops, so test that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if it has already been decremented), and if it is any other value, discard the frame. The RBridge Channel Header in the frame MUST have the MH bit equal to one, and if it is zero, discard the frame.
o 颤音BFD回波帧应该正好经过两个跃点，因此测试接收到的颤音报头跃点计数是否为0x3E（即，如果已递减，则为0x3D），如果为任何其他值，则丢弃该帧。帧中的RBridge通道头的MH位必须等于1，如果为零，则丢弃帧。
The TRILL BFD parameters on an RBridge are configurable. The default values are the same as in the IP BFD case [RFC5881], except where specified in this document, such as for hop count.
RBridge上的颤音BFD参数是可配置的。默认值与IP BFD案例[RFC5881]中的值相同，除非本文档中另有规定，例如跃点计数。
It is up to the operator of an RBridge campus to configure the rates at which TRILL BFD frames are transmitted on a link to avoid congestion (e.g., link, input/output (I/O), CPU) and false failure detection. See also the discussion of congestion in Section 2 of [RFC5881].
RBridge园区的运营商负责配置TRILL BFD帧在链路上传输的速率，以避免拥塞（例如链路、输入/输出（I/O）、CPU）和错误故障检测。另请参见[RFC5881]第2节中关于拥塞的讨论。
As stated in [RFC5880]:
如[RFC5880]所述：
It is worth noting that a single BFD session does not consume a large amount of bandwidth. An aggressive session that achieves a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, for a total of around 48 kilobits per second of bandwidth consumption in each direction.
值得注意的是，单个BFD会话不会消耗大量带宽。通过使用16.7毫秒的传输间隔和3的检测乘数，达到50毫秒检测时间的主动会话将每秒生成60个数据包。线路上每个数据包的最大长度约为100字节，每个方向的带宽消耗总量约为每秒48千位。
Consistent with TRILL's goal of being able to operate with minimum configuration, the default for BFD authentication between neighbor RBridges is based on the state of the IS-IS shared secret authentication for Hellos between those RBridges as detailed below. The BFD authentication algorithm and methods in this section MUST be implemented at an RBridge if TRILL IS-IS authentication and BFD are implemented at that RBridge. If such BFD authentication is configured, then its configuration is not restricted by the configuration of IS-IS security.
与TRILL能够以最小配置运行的目标一致，相邻RBridge之间的BFD身份验证的默认设置基于这些RBridge之间HELOS的is-is共享秘密身份验证的状态，如下所述。如果TRILL IS-IS认证和BFD在RBridge上实现，则本节中的BFD认证算法和方法必须在RBridge上实现。如果配置了此类BFD身份验证，则其配置不受is-is安全配置的限制。
If IS-IS authentication is not in effect between neighbor RBridges, then, by default, TRILL BFD between those RBridges is also unsecured.
如果相邻RBridge之间的IS-IS身份验证无效，则默认情况下，这些RBridge之间的TRILL BFD也是不安全的。
If such IS-IS authentication is in effect, then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges MUST use BFD Meticulous Keyed SHA1 authentication [RFC5880]. The BFD authentication keys between neighbor RBridges by default are derived
如果此类IS-IS认证有效，则除非另有配置，否则在这些RBridge之间发送的TRILL BFD控制帧必须使用BFD加密SHA1认证[RFC5880]。默认情况下，将派生相邻RBridge之间的BFD身份验证密钥
from the IS-IS shared secret authentication keys for Hellos between those RBridges as detailed below. However, such BFD authentication keys MAY be configured to some other value.
从IS-IS共享的秘密身份验证密钥中，在这些RBridge之间为Hellos提供身份验证密钥，详情如下。然而，这种BFD认证密钥可以配置为一些其他值。
HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ), IS-IS-shared-key )
HMAC-SHA256（（“颤音BFD控制”| originPortID | originSysID）是共享密钥）
In the above, "|" indicates concatenation; HMAC-SHA256 is as described in [FIPS180] and [RFC6234]; and "TRILL BFD Control" is the 17-byte US ASCII [ASCII] string indicated that is then concatenated with the 2-byte Port ID of the originating port and the 6-byte IS-IS System ID of the originating RBridge, the last two items being in network byte order. The Port and System IDs are included to minimize exposure of the same key to improve resistance to cryptanalysis. IS-IS-shared-key is secret keying material being used for IS-IS authentication on the link.
在上述情况下，“|”表示串联；HMAC-SHA256如[FIPS180]和[RFC6234]所述；“TRILL BFD Control”（TRILL BFD Control）是表示的17字节US ASCII[ASCII]字符串，然后与发起端口的2字节端口ID和发起RBridge的6字节is-is系统ID连接，最后两项按网络字节顺序排列。包括端口和系统ID以最大限度地减少同一密钥的暴露，从而提高对密码分析的抵抗力。IS共享密钥是用于链接上IS-IS身份验证的密钥材料。
The use of the above derived key is accomplished by associating the above default authentication type and key with the Key ID of the IS-IS-shared-key used in the derivation and then using that Key ID in the Authentication Section of the BFD Control frame OAM protocol-specific data. Also, Auth Type would be 5, and Auth Len would be 28 in the Authentication Section. RBridges MAY be configured to use other BFD security modes or keying material or configured to use no security.
通过将上述默认认证类型和密钥与在派生中使用的is is共享密钥的密钥ID相关联，然后在BFD控制帧OAM协议特定数据的认证部分中使用该密钥ID，来实现上述派生密钥的使用。此外，身份验证部分中的Auth Type为5，Auth Len为28。RBridges可配置为使用其他BFD安全模式或键控材料，或配置为不使用安全。
Authentication for TRILL BFD Echo is a local implementation issue as BFD Echo frames are authenticated by their sender when returned by a neighbor. However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor should be authenticated, and such authentication should use different keying material from other types of authentication. For example, it could use keying material derived as follows, where "|" indicates concatenation:
TRILL BFD Echo的身份验证是一个本地实现问题，因为BFD Echo帧在由邻居返回时由其发送方进行身份验证。但是，如果TRILL IS-IS和BFD控件正在向邻居进行身份验证，并且BFD Echo正在使用，则应该对该邻居返回的BFD Echo帧进行身份验证，并且这种身份验证应该使用与其他类型身份验证不同的键控材料。例如，它可以使用如下派生的关键帧材质，其中“|”表示串联：
HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ), IS-IS-shared-key )
HMAC-SHA256（（“颤音BFD回音”| originPortID | originSysID）是共享键）
BFD over TRILL utilizes the RBridge Channel extension to the TRILL protocol and is generally analogous to BFD over IP. As such, the BFD authentication facility is available to authenticate BFD-over-TRILL packet payloads, but no encryption or other security features are provided at the BFD-over-TRILL level. See the following:
TRILL上的BFD利用TRILL协议的RBridge信道扩展，通常类似于IP上的BFD。因此，BFD身份验证功能可用于通过TRILL数据包有效负载对BFD进行身份验证，但在BFD over TRILL级别上未提供加密或其他安全功能。见下文：
- [RFC5881] for general BFD security considerations,
- [RFC5881]对于一般BFD安全考虑，
- [RFC7178] for general RBridge Channel security considerations, and
- [RFC7178]用于一般RBridge通道安全考虑，以及
- [RFC6325] for general TRILL protocol security considerations.
- [RFC6325]用于一般TRILL协议安全考虑。
Section 3.2 describes security concerns with multi-hop BFD Control packets and failure to check the TRILL Header M bit in BFD Control packets.
第3.2节描述了多跳BFD控制数据包的安全问题，以及未能检查BFD控制数据包中的TRILL报头M位。
IANA has allocated two RBridge Channel protocol numbers [RFC7178] from the Standards Action range, as follows:
IANA已从标准行动范围中分配了两个RBridge通道协议编号[RFC7178]，如下所示：
Protocol Number
-------- ------
BFD Control 0x002
BFD Echo 0x003
Protocol Number
-------- ------
BFD Control 0x002
BFD Echo 0x003
The authors would like to specially thank Dave Katz, an author of [RFC5880] and [RFC5881], from which some material herein has been reproduced.
作者要特别感谢Dave Katz，他是[RFC5880]和[RFC5881]的作者，本文中的一些材料已从中复制。
The following individuals are thanked for their comments and suggestions: Scott Bradner, Stewart Bryant, Stephen Farrell, Eric Gray, Brian Haberman, Barry Leiba, Erik Nordmark, John Scudder, Robert Sparks, Martin Stiemerling, and Sean Turner.
感谢以下个人的评论和建议：斯科特·布拉德纳、斯图尔特·布莱恩特、斯蒂芬·法雷尔、埃里克·格雷、布赖恩·哈伯曼、巴里·莱巴、埃里克·诺德马克、约翰·斯卡德尔、罗伯特·斯帕克斯、马丁·斯蒂梅林和肖恩·特纳。
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.41986。
[FIPS180] National Institute of Science and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard (FIPS) 180-4, March 2012, <http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf>.
[FIPS180]国家科学技术研究所，“安全哈希标准（SHS）”，联邦信息处理标准（FIPS）180-42012年3月<http://csrc.nist.gov/ 出版物/fips/fips180-4/fips-180-4.pdf>。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，第二版，2002年11月。
[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月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年6月。
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, April 2011.
[RFC6213]Hopps，C.和L.Ginsberg，“IS-IS BFD启用的TLV”，RFC 6213，2011年4月。
[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月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，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月。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE Std 802.1AX-2008, January 2008.
[802.1AX]IEEE，“局域网和城域网的IEEE标准——链路聚合”，IEEE标准802.1AX-2008，2008年1月。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q-2011，2011年8月。
[MultiBFD] Katz, D. and D. Ward, "BFD for Multipoint Networks", Work in Progress, February 2014.
[MultiBFD]Katz，D.和D.Ward，“多点网络的BFD”，正在进行的工作，2014年2月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，2011年5月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 63612011年8月。
[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014.
[RFC7173]Yong，L.，Eastlake 3rd，D.，Aldrin，S.，和J.Hudson，“使用伪线的大量链路（TRILL）传输的透明互连”，RFC 7173，2014年5月。
Authors' Addresses
作者地址
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
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
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95138 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95138
EMail: dward@cisco.com
EMail: dward@cisco.com
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
美国加利福尼亚州桑尼维尔西伊夫林大道1089号Ayan Banerjee Cumulus Networks 94086
EMail: ayabaner@gmail.com
EMail: ayabaner@gmail.com