Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 7212 Blue Sun
Category: Standards Track S. Bryant
ISSN: 2070-1721 Cisco Systems
M. Bocci
Alcatel-Lucent
June 2014
Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 7212 Blue Sun
Category: Standards Track S. Bryant
ISSN: 2070-1721 Cisco Systems
M. Bocci
Alcatel-Lucent
June 2014
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
MPLS通用关联信道（G-ACh）播发协议
Abstract
摘要
The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.
MPLS通用关联信道（G-ACh）提供与标签交换路径（LSP）、伪线或各种协议可在其上流动的部分（链路）关联的辅助逻辑数据信道。这些协议通常用于提供与主数据通道相关联的操作、管理和维护（OAM）机制。本文档规定了简单的过程，通过这些过程，LSP、伪线或区段的端点可以将其功能和配置参数或其他特定于应用程序的信息通知其他端点。然后，该信息可由接收器用于验证或调整其本地配置，并由网络运营商用于诊断目的。
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/rfc7212.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7212.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 8
3.2. Applications Data Block . . . . . . . . . . . . . . . . . 9
3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 10
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 10
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 11
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 11
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 12
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 13
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 14
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Message Transmission . . . . . . . . . . . . . . . . . . 14
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 15
6. Message Authentication . . . . . . . . . . . . . . . . . . . 16
6.1. Authentication Key Identifiers . . . . . . . . . . . . . 16
6.2. Authentication Process . . . . . . . . . . . . . . . . . 17
6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 18
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Associated Channel Type Allocation . . . . . . . . . . . 20
10.2. Allocation of Address Family Numbers . . . . . . . . . . 20
10.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 8
3.2. Applications Data Block . . . . . . . . . . . . . . . . . 9
3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 10
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 10
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 11
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 11
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 12
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 13
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 14
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Message Transmission . . . . . . . . . . . . . . . . . . 14
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 15
6. Message Authentication . . . . . . . . . . . . . . . . . . . 16
6.1. Authentication Key Identifiers . . . . . . . . . . . . . 16
6.2. Authentication Process . . . . . . . . . . . . . . . . . 17
6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 18
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Associated Channel Type Allocation . . . . . . . . . . . 20
10.2. Allocation of Address Family Numbers . . . . . . . . . . 20
10.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
The MPLS Generic Associated Channel (G-ACh) is defined and described in [RFC5586]. It provides an auxiliary logical data channel over which a variety of protocols may flow. Each such data channel is associated with an MPLS Label Switched Path (LSP), a pseudowire, or a section (link). An important use of the G-ACh and the protocols it supports is to provide Operations, Administration, and Maintenance (OAM) [RFC6291] capabilities for the associated LSP, pseudowire, or section. Examples of such capabilities include Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5085]; Bidirectional Forwarding Detection (BFD) for MPLS [RFC5884]; and MPLS packet loss, delay, and throughput measurement [RFC6374]; as well as OAM functions developed for the MPLS Transport Profile (MPLS-TP) [RFC5921].
MPLS通用关联信道（G-ACh）在[RFC5586]中定义和描述。它提供了一个辅助逻辑数据通道，各种协议可以通过该通道流动。每个这样的数据信道与MPLS标签交换路径（LSP）、伪线或部分（链路）相关联。G-ACh及其支持的协议的一个重要用途是为相关LSP、伪线或段提供操作、管理和维护（OAM）[RFC6291]功能。此类功能的示例包括伪线虚拟电路连接验证（VCCV）[RFC5085]；用于MPLS的双向转发检测（BFD）[RFC5884]；以及MPLS数据包丢失、延迟和吞吐量测量[RFC6374]；以及为MPLS传输配置文件（MPLS-TP）[RFC5921]开发的OAM功能。
This document specifies procedures for an MPLS Label Switching Router (LSR) to advertise its capabilities and configuration parameters, or other application-specific information, to its peers over LSPs, pseudowires, and sections. Receivers can then make use of this information to validate or adjust their own configurations, and network operators can make use of it to diagnose faults and configuration inconsistencies between endpoints. Note that in this document the term "application" refers to an application that uses the protocol defined herein (and hence operates over the G-ACh), and it should not be confused with an end-user application.
本文档规定了MPLS标签交换路由器（LSR）通过LSP、伪线和区段向其对等方公布其功能和配置参数或其他特定于应用程序的信息的过程。然后，接收器可以利用这些信息来验证或调整自己的配置，网络运营商可以利用这些信息来诊断端点之间的故障和配置不一致。注意，在本文件中，术语“应用程序”指使用本文定义的协议的应用程序（因此在G-ACh上运行），不应将其与最终用户应用程序混淆。
The main principle guiding the design of the MPLS G-ACh Advertisement Protocol (GAP) is simplicity. The protocol provides a one-way method of distributing information about the sender. How this information is used by a given receiver is a local matter. The data elements distributed by the GAP are application specific and, except for those associated with the GAP itself, are outside the scope of this document. An IANA registry has been created to allow GAP applications to be defined as needed.
指导MPLS G-ACh广告协议（GAP）设计的主要原则是简单性。该协议提供了一种分发发送方信息的单向方法。给定接收者如何使用这些信息是一个局部问题。GAP分发的数据元素是特定于应用程序的，除与GAP本身相关的数据元素外，不在本文档的范围内。已创建IANA注册表，以允许根据需要定义GAP应用程序。
The assignment of application identifiers and associated GAP parameters for protocols other than the GAP itself is outside the scope of this document. Such assignments can be made in subsequent documents according to the IANA considerations specified here.
除了GAP本身之外，协议的应用程序标识符和相关GAP参数的分配不在本文档的范围内。根据此处规定的IANA注意事项，可在后续文件中进行此类分配。
It is frequently useful in a network for a node to have general information about its adjacent nodes, i.e., those nodes to which it has links. At a minimum, this allows a human operator or management application with access to the node to determine which adjacent nodes this node can see; this is helpful when troubleshooting connectivity problems. A typical example of an "adjacency awareness protocol" is
在网络中，节点通常有关于其相邻节点的一般信息，即其链接到的节点。至少，这允许具有节点访问权限的人工操作员或管理应用程序确定该节点可以看到哪些相邻节点；这在排除连接问题时很有帮助。“邻接感知协议”的一个典型示例是
the Link Layer Discovery Protocol [LLDP], which can provide various pieces of information about adjacent nodes in Ethernet networks, such as system name, basic functional capabilities, link speed/duplex settings, and maximum supported frame size. Such data is useful both for human diagnostics and for automated detection of configuration inconsistencies.
链路层发现协议[LLDP]，它可以提供有关以太网中相邻节点的各种信息，例如系统名称、基本功能能力、链路速度/双工设置以及支持的最大帧大小。这些数据对于人类诊断和配置不一致的自动检测都很有用。
In MPLS networks, the G-ACh provides a convenient link-layer-agnostic means for communication between LSRs that are adjacent at the link layer. The G-ACh advertisement protocol presented in this document thus allows LSRs to exchange information of a similar sort to that supported by LLDP for Ethernet links. The GAP, however, does not depend on the specific link-layer protocol in use, and it can be used to advertise information on behalf of any MPLS application.
在MPLS网络中，G-ACh为链路层相邻的LSR之间的通信提供了方便的链路层无关方式。因此，本文中介绍的G-ACh播发协议允许LSR交换与LLDP支持的以太网链路类似的信息。然而，GAP并不取决于使用的特定链路层协议，它可以用于代表任何MPLS应用程序发布信息。
In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] that do not also support IP, the normal protocols used to determine the Ethernet address of an adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery [RFC4861], are not available. One possible use of the G-ACh advertisement protocol is to discover the Ethernet media access control addresses of MPLS-TP nodes lacking IP capability [RFC7213]. However, where it is anticipated that the only data that needs to be exchanged between LSRs over an Ethernet link are their Ethernet addresses, then the operator may instead choose to use LLDP for that purpose.
在基于MPLS传输配置文件（MPLS-TP）[RFC5921]且不支持IP的网络中，用于确定相邻MPLS节点的以太网地址的常规协议（如地址解析协议[RFC0826]和IP版本6邻居发现[RFC4861]）不可用。G-ACh播发协议的一个可能用途是发现缺少IP能力的MPLS-TP节点的以太网媒体访问控制地址[RFC7213]。然而，如果预计需要通过以太网链路在LSR之间交换的唯一数据是它们的以太网地址，那么运营商可以选择为此目的使用LLDP。
The applicability of the G-ACh advertisement protocol is not limited to link-layer adjacency, either in terms of message distribution or message content. The G-ACh exists for any MPLS LSP or pseudowire, so GAP messages can be exchanged with remote LSP or pseudowire endpoints. The content of GAP messages is extensible in a simple manner and can include any kind of information that might be useful to MPLS LSRs connected by links, LSPs, or pseudowires. For example, in networks that rely on the G-ACh for OAM functions, GAP messages might be used to inform adjacent LSRs of a node's OAM capabilities and configuration parameters.
G-ACh播发协议的适用性不限于链路层邻接，无论是在消息分布还是消息内容方面。G-ACh适用于任何MPLS LSP或伪线，因此可以与远程LSP或伪线端点交换GAP消息。GAP消息的内容可以以简单的方式扩展，并且可以包括可能对通过链路、LSP或伪线连接的MPLS LSR有用的任何类型的信息。例如，在依赖G-ACh实现OAM功能的网络中，间隙消息可用于通知相邻lsr节点的OAM能力和配置参数。
Term Definition
----- -------------------------------------------
G-ACh Generic Associated Channel
GAL G-ACh Label
GAP G-ACh Advertisement Protocol
LSP Label Switched Path
OAM Operations, Administration, and Maintenance
Term Definition
----- -------------------------------------------
G-ACh Generic Associated Channel
GAL G-ACh Label
GAP G-ACh Advertisement Protocol
LSP Label Switched Path
OAM Operations, Administration, and Maintenance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The G-ACh Advertisement Protocol has a simple one-way mode of operation: a device configured to send information for a particular data channel (MPLS LSP, pseudowire, or section) transmits GAP messages over the G-ACh associated with the data channel. The payload of a GAP message is a collection of Type-Length-Value (TLV) objects, organized on a per-application basis. An IANA registry has been created to identify specific applications. Application TLV objects primarily contain static data that the receiver is meant to retain for a period of time, but they may also represent metadata or special processing instructions.
G-ACh广告协议具有简单的单向操作模式：配置为发送特定数据信道（MPLS LSP、伪线或区段）的信息的设备通过与数据信道相关联的G-ACh传输间隙消息。GAP消息的有效负载是类型长度值（TLV）对象的集合，以每个应用程序为基础进行组织。已创建IANA注册表以识别特定的应用程序。应用程序TLV对象主要包含接收方打算保留一段时间的静态数据，但它们也可能表示元数据或特殊处理指令。
Each GAP message can contain data for several applications. A sender may transmit a targeted update that refreshes the data for a subset of applications without affecting the data of other applications sent in a previous message. GAP messages are processed in the order in which they are received.
每个间隙消息可以包含多个应用程序的数据。发送方可以发送刷新应用程序子集的数据的目标更新，而不影响在先前消息中发送的其他应用程序的数据。间隙消息按接收顺序进行处理。
For example, a GAP message might be sent containing the following data:
例如，发送的间隙消息可能包含以下数据：
Application A: A-TLV4, A-TLV15, A-TLV9
应用程序A:A-TLV4、A-TLV15、A-TLV9
Application B: B-TLV1, B-TLV3
应用B:B-TLV1，B-TLV3
Application C: C-TLV6,
应用程序C:C-TLV6，
where the TLVx refers to an example GAP TLV.
其中，TLVx指的是示例间隙TLV。
A second message might then be sent containing:
然后可能会发送第二条消息，其中包含：
Application B: B-TLV7, B-TLV3
应用程序B:B-TLV7，B-TLV3
Upon receiving the second message, the receiver retains B-TLV1 from the first message and adds B-TLV7 to its B-database. How it handles the new B-TLV3 depends on the rules B has specified for this object type; this object could replace the old one or be combined with it in some way. The second message has no effect on the databases maintained by the receiver for Applications A and C.
在接收到第二条消息时，接收方保留第一条消息中的B-TLV1，并将B-TLV7添加到其B-database中。它如何处理新的B-TLV3取决于B为此对象类型指定的规则；此对象可以替换旧对象，或者以某种方式与之组合。第二条消息对接收方为应用程序A和C维护的数据库没有影响。
The rate at which GAP messages are transmitted is at the discretion of the sender and may fluctuate over time as well as differ per application. Each message contains, for each application it describes, a lifetime that informs the receiver how long to wait before discarding the data for that application.
GAP消息的传输速率由发送方自行决定，可能随时间而波动，也可能因应用而异。对于它描述的每个应用程序，每条消息都包含一个生存期，该生存期通知接收方在丢弃该应用程序的数据之前需要等待多长时间。
The GAP itself provides no fragmentation and reassembly mechanisms. In the event that an application wishes to send larger chunks of data via GAP messages than fall within the limits of packet size, it is the responsibility of the application to fragment its data accordingly. It is the responsibility of the application and the network operator to ensure that the use of the GAP does not congest the link to the peer.
间隙本身不提供碎片和重组机制。如果应用程序希望通过GAP消息发送大于数据包大小限制范围的数据块，则应用程序有责任相应地对其数据进行分段。应用程序和网络运营商有责任确保GAP的使用不会阻塞到对等方的链路。
The GAP is designed to run over a unidirectional channel. However, where the channel is bidirectional, communication may be optimized through the use of a number of messages defined for transmission from the receiver back to the sender. These are optimizations and are not required for protocol operation.
间隙设计为在单向通道上运行。然而，在信道是双向的情况下，可以通过使用为从接收机传回发送方而定义的多个消息来优化通信。这些是优化，协议操作不需要这些优化。
An Associated Channel Header (ACH) Channel Type has been allocated for the GAP as follows:
已为GAP分配了关联的信道头（ACH）信道类型，如下所示：
Protocol Channel Type
---------------------------------- ------------
G-ACh Advertisement Protocol 0x0059
Protocol Channel Type
---------------------------------- ------------
G-ACh Advertisement Protocol 0x0059
For this Channel Type, as noted in [RFC7026], the ACH SHALL NOT be followed by the ACH TLV Header defined in [RFC5586].
对于这种信道类型，如[RFC7026]中所述，ACH后面不应跟随[RFC5586]中定义的ACH TLV头。
Fields in this document shown as Reserved or Resv are reserved for future specification and MUST be set to zero. All integer values for fields defined in this document SHALL be encoded in network byte order.
本文档中显示为Reserved或Resv的字段保留用于将来的规范，必须设置为零。本文件中定义的字段的所有整数值应按网络字节顺序编码。
A GAP message consists of a fixed header followed by a GAP payload. The payload of a GAP message is an Application Data Block (ADB) consisting of one or more block elements. Each block element contains an application identifier, a lifetime, and a series of zero or more TLV objects for the application it describes.
间隙消息由固定的报头和间隙有效负载组成。GAP消息的有效负载是由一个或多个块元素组成的应用程序数据块（ADB）。每个块元素包含一个应用程序标识符、一个生存期，以及它所描述的应用程序的一系列零个或多个TLV对象。
Malformed GAP messages MUST be discarded by the receiver, although an error MAY be logged. If the error is logged remotely, a suitable form of rate limiting SHOULD be used to prevent excessive logging messages being transmitted over the network.
格式错误的间隙消息必须由接收器丢弃，尽管可能会记录错误。如果远程记录错误，则应使用适当形式的速率限制，以防止通过网络传输过多的日志消息。
Implementations of this protocol version MUST set reserved fields in the message formats that follow to all zero bits when sending and ignore any value when receiving messages.
此协议版本的实现必须在消息格式中设置保留字段，这些字段在发送时跟随所有零位，在接收消息时忽略任何值。
The following figure shows the format of a G-ACh Advertisement Protocol message, which follows the Associated Channel Header (ACH):
下图显示了G-ACh播发协议消息的格式，该消息遵循关联的通道头（ACh）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Application Data Block (ADB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Application Data Block (ADB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GAP Message Format
图1:GAP消息格式
The meanings of the fields are:
这些字段的含义如下：
Version (4 bits): Protocol version. This is set to zero.
版本（4位）：协议版本。这被设置为零。
Reserved (12 bits): MUST be sent as zero.
保留（12位）：必须作为零发送。
Message Length (16 bits): Size in octets of this message, i.e., of the portion of the packet following the Associated Channel Header.
消息长度（16位）：此消息的大小（以八位字节为单位），即相关信道报头后的数据包部分。
Message Identifier (MI) (32 bits): Unique identifier of this message. For disambiguation, a sender MUST NOT reuse an MI over a given channel until it is confident that all ADBs associated with it have been expired by the receiver. The sole purpose of this field is duplicate detection in the event of a message burst (Section 5.1).
消息标识符（MI）（32位）：此消息的唯一标识符。为了消除歧义，发送方不得在给定信道上重复使用MI，直到其确信与之相关的所有ADB已由接收方过期。该字段的唯一用途是在消息突发的情况下进行重复检测（第5.1节）。
Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, as specified in Section 6 of [RFC5905].
时间戳：64位网络时间协议（NTP）传输时间戳，如[RFC5905]第6节所述。
An ADB consists of one or more elements of the following format:
ADB由以下格式的一个或多个元素组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
Figure 2: Application Data Block Element
图2：应用程序数据块元素
Application ID (16 bits): Identifies the application this element describes; an IANA registry has been created to track the values for this field. More than one block element with the same Application ID may be present in the same ADB, and block elements with different Application IDs may also be present in the same ADB. The protocol rules for the mechanism, including what ADB elements are present and which TLVs are contained in an ADB element, are to be defined in the document that specifies the application-specific usage.
应用程序ID（16位）：标识此元素描述的应用程序；已创建IANA注册表来跟踪此字段的值。同一ADB中可能存在多个具有相同应用程序ID的块元素，并且同一ADB中也可能存在具有不同应用程序ID的块元素。机制的协议规则，包括存在哪些ADB元素以及ADB元素中包含哪些TLV，将在指定应用程序特定用途的文档中定义。
Element Length (16 bits): Specifies the total length in octets of this block element (including the Application ID and Element Length fields).
元素长度（16位）：指定此块元素的总长度（以八位字节为单位）（包括应用程序ID和元素长度字段）。
Lifetime field (16 bits): Specifies how long, in seconds, the receiver should retain the data in this message (i.e., it specifies the lifetime of the static data carried in the TLV set of this ADB). For TLVs not carrying static data, the Lifetime is of no significance. The sender of a GAP message indicates this by setting the Lifetime field to zero. If the Lifetime is zero, TLVs in this ADB are processed by the receiver, and the data associated with these TLV types is immediately marked as expired. If the ADB contains no TLVs, the receiver expires all data associated with TLVs previously sent to this application.
生存期字段（16位）：指定接收器在该消息中保留数据的时间（以秒为单位）（即，它指定该ADB的TLV集合中携带的静态数据的生存期）。对于不携带静态数据的TLV，寿命没有意义。间隙消息的发送者通过将生存期字段设置为零来指示这一点。如果生存期为零，接收器将处理此ADB中的TLV，并立即将与这些TLV类型相关的数据标记为过期。如果ADB不包含TLV，则接收器会使先前发送到此应用程序的与TLV相关的所有数据过期。
The remainder of the Application Data Block element consists of a sequence of zero or more TLV objects that use the format defined in Section 3.3.
应用程序数据块元素的其余部分由零个或多个TLV对象组成，这些对象使用第3.3节中定义的格式。
The scope of an ADB element is an application instance attached to a specific channel between a specific source-destination pair, and the
ADB元素的作用域是附加到特定源-目的地对之间的特定通道的应用程序实例，以及
Lifetime field specifies the lifetime of the ADB element data in that specific context.
Lifetime字段指定特定上下文中ADB元素数据的生存期。
GAP TLV objects use the following format:
间隙TLV对象使用以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TLV Object Format
图3:TLV对象格式
Type (8 bits): Identifies the TLV Object and is scoped to a specific application; each application creates an IANA registry to track its Type values.
类型（8位）：标识TLV对象，并适用于特定应用程序；每个应用程序都创建一个IANA注册表来跟踪其类型值。
Reserved (8 bits): MUST be sent as zero.
保留（8位）：必须作为零发送。
Length (16 bits): The length in octets of the Value field. The Value field need not be padded to provide alignment.
长度（16位）：值字段的长度（以八位字节为单位）。值字段不需要填充以提供对齐。
GAP messages do not contain a checksum. If validation of message integrity is desired, the authentication procedures in Section 6 should be used.
间隙消息不包含校验和。如果需要验证消息完整性，则应使用第6节中的身份验证程序。
The GAP supports several TLV objects related to its own operation via the Application ID 0x0000. These objects represent metadata and processing instructions rather than static data that is meant to be retained. When an ADB element for the GAP is present in a GAP message, it MUST precede other elements. This is particularly important for the correct operation of the Flush message (Section 4.3).
GAP通过应用程序ID 0x0000支持多个与其自身操作相关的TLV对象。这些对象表示元数据和处理指令，而不是要保留的静态数据。当GAP消息中存在GAP的ADB元素时，它必须位于其他元素之前。这对于冲洗信息的正确操作尤其重要（第4.3节）。
Any application using the GAP inherits the ability to use facilities provided by Application 0x0000.
任何使用GAP的应用程序都继承了使用应用程序0x0000提供的功能。
Application 0x0000 GAP messages MUST be processed in the order in which they are received.
必须按照接收的顺序处理应用程序0x0000间隙消息。
The Source Address object identifies the sending device and possibly the transmitting interface and the channel; it has the following format:
源地址对象标识发送设备以及可能的发送接口和信道；其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (16 bits) | Address Family (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (16 bits) | Address Family (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Source Address TLV Format
图4：源地址TLV格式
The Address Family field indicates the type of the address; it SHALL be set to one of the assigned values in the IANA "Address Family Numbers" registry.
地址族字段指示地址的类型；应将其设置为IANA“地址系列号”注册表中的指定值之一。
In IP networks, a Source Address SHOULD be included in GAP messages and set to an IP address of the sending device; when the channel is a link, this address SHOULD be an address of the transmitting interface.
在IP网络中，源地址应包含在GAP消息中，并设置为发送设备的IP地址；当通道为链路时，该地址应为传输接口的地址。
In non-IP MPLS-TP networks, a Source Address SHOULD be included in GAP messages and set to the endpoint identifier of the channel. The formats of these channel identifiers SHALL be as given in Sections 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and Length fields shown in those sections). IANA has allocated Address Family Numbers for these identifiers; see Section 10.2.
在非IP MPLS-TP网络中，源地址应包含在GAP消息中，并设置为通道的端点标识符。这些通道标识符的格式应符合[RFC6428]第3.5.1、3.5.2和3.5.3节的规定（不包括这些章节中显示的初始类型和长度字段）。IANA已为这些标识符分配了地址系列号；见第10.2节。
On multipoint channels, a Source Address TLV is REQUIRED.
在多点通道上，需要源地址TLV。
This object is a request by the sender for the receiver to transmit an immediate unicast GAP update to the sender. If the Length field is zero, this signifies that an update for all applications is
此对象是发送方请求接收方立即向发送方发送单播间隔更新。如果长度字段为零，则表示所有应用程序的更新均为零
requested. Otherwise, the Value field specifies the applications for which an update is requested, in the form of a sequence of Application IDs:
请求。否则，值字段以应用程序ID序列的形式指定请求更新的应用程序：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID 1 | Application ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID 1 | Application ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GAP Request TLV Format
图5:GAP请求TLV格式
The intent of this TLV is to request the immediate transmission of data following a local event such as a restart, rather than waiting for a periodic update. Applications need to determine what information is meaningful to send in response to such a request. The inclusion of an Application ID in a Request TLV does not guarantee that the response will provide information for that application. The responder may also include information for applications not included in the request. A receiver SHOULD discard GAP Request messages that arrive at a rate in excess of that which is considered reasonable for the application.
此TLV的目的是请求在本地事件（如重启）后立即传输数据，而不是等待定期更新。应用程序需要确定在响应此类请求时发送哪些有意义的信息。在请求TLV中包含应用程序ID并不保证响应将为该应用程序提供信息。响应者还可以包括请求中未包括的应用的信息。接收方应丢弃到达速率超过应用程序认为合理速率的GAP请求消息。
For an Application ID 0x0000 GAP Request, it is meaningful to respond with the Source Address.
对于应用程序ID 0x0000间隙请求，使用源地址进行响应是有意义的。
This TLV is considered to be part of the GAP and thus does not need to be retained. The reception of the TLV may however be recorded for management purposes.
该TLV被视为间隙的一部分，因此无需保留。但是，出于管理目的，可以记录TLV的接收情况。
This object is an instruction to the receiver to flush the GAP data for all applications associated with this (sender, channel) pair. It is a null object, i.e., its Length is set to zero.
此对象是对接收器的指令，用于刷新与此（发送器、通道）对关联的所有应用程序的间隙数据。它是空对象，即其长度设置为零。
The GAP Flush instruction does not apply to data contained in the message carrying the GAP Flush TLV object itself. Any application data contained in the same message SHALL be processed and retained by the receiver as usual.
GAP Flush指令不适用于包含在携带GAP Flush TLV对象本身的消息中的数据。同一消息中包含的任何应用程序数据应由接收方像往常一样进行处理和保留。
The Flush TLV type is 2.
嵌入式TLV类型为2。
This TLV is considered to be part of the GAP and thus does not need to be retained. The reception of the TLV may however be recorded for management purposes.
该TLV被视为间隙的一部分，因此无需保留。但是，出于管理目的，可以记录TLV的接收情况。
This object is a request to the receiver to cease sending GAP updates to the transmitter over the current channel for the specified duration. Duration is a 16-bit non-negative integer in units of seconds. The receiver MAY accept and act on the request, MAY ignore the request, or MAY resume transmissions at any time according to implementation or configuration choices, and depending on local pragmatics. The format of this object is as follows:
此对象是对接收器的请求，要求在指定的持续时间内停止通过当前通道向发射器发送间隙更新。持续时间是以秒为单位的16位非负整数。接收机可以根据实现或配置选择，并且取决于本地语用，随时接受请求并对其采取行动，可以忽略请求，或者可以恢复传输。该对象的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GAP Suppress TLV Format
图6：间隙抑制TLV格式
If the Length is set to 2, i.e., if the list of Application IDs is empty, then suppression of all GAP messages is requested; otherwise, suppression of only those updates pertaining to the listed applications is requested. A duration of zero cancels any existing suppress requests for the listed applications.
如果长度设置为2，即，如果应用程序ID列表为空，则请求抑制所有间隙消息；否则，仅请求抑制与列出的应用程序相关的更新。持续时间为零将取消列出的应用程序的任何现有抑制请求。
This object makes sense only for point-to-point channels or when the sender is receiving unicast GAP updates.
此对象仅适用于点对点通道或发送方接收单播间隔更新时。
This object is used to provide authentication and integrity validation for a GAP message. It has the following format:
此对象用于为GAP消息提供身份验证和完整性验证。其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=4 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=4 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GAP Authentication TLV Format
图7:GAP认证TLV格式
The data and procedures associated with this object are explained in Section 6.
第6节解释了与该对象相关的数据和程序。
G-ACh Advertisement Protocol message transmission SHALL operate on a per-data-channel basis and be configurable by the operator accordingly.
G-ACh广告协议消息传输应在每个数据通道的基础上运行，并由运营商进行相应的配置。
Because GAP message transmission may be active for many logical channels on the same physical interface, message transmission timers SHOULD be randomized across the channels supported by a given interface so as to reduce the likelihood of large synchronized message bursts.
由于GAP消息传输对于同一物理接口上的多个逻辑信道可能是活动的，因此消息传输计时器应在给定接口支持的信道上随机分配，以降低大型同步消息突发的可能性。
The Message Identifier (MI) uniquely identifies this message and its value is set at the sender's discretion. It MUST NOT be assumed to be a sequence number. The scope of an MI is a channel between a specific source-destination pair.
消息标识符（MI）唯一标识此消息，其值由发送方自行设置。不能假设它是一个序列号。MI的范围是特定源-目标对之间的通道。
The Timestamp field SHALL be set to the time at which this message is transmitted.
时间戳字段应设置为发送此消息的时间。
The Lifetime field of each Application Data Block element SHALL be set to the number of seconds the receiver is advised to retain the data associated with this message and application.
每个应用数据块元素的寿命字段应设置为建议接收器保留与此消息和应用相关的数据的秒数。
When the transmitter wishes the data previously sent in an ADB element to persist, then it must refresh the ADB element by sending another update. Refresh times SHOULD be set in such a way that at least three updates will be sent prior to Lifetime expiration. For example, if the Lifetime is set to 210 seconds, then updates should be sent at least once every 60 seconds.
当发送器希望先前在ADB元素中发送的数据保持不变时，则必须通过发送另一个更新来刷新ADB元素。刷新时间的设置方式应确保在生命周期到期之前至少发送三次更新。例如，如果生存期设置为210秒，则更新应至少每60秒发送一次。
A sender may signal that previously sent data SHOULD be marked as expired by setting the ADB element lifetime to zero as previously described in Section 3.
发送方可通过将ADB元素寿命设置为零（如第3节所述），发出信号，表明先前发送的数据应标记为已过期。
In some cases, an application may desire additional reliability for the delivery of some of its data. When this is the case, the transmitter MAY send several (for example, three) instances of the message in succession, separated by a delay appropriate to, or specified by, the application. For example, this procedure might be invoked when sending a Flush instruction following device reset. The expectation is that the receiver will detect duplicate messages using the MI.
在某些情况下，应用程序可能需要提供其某些数据的额外可靠性。在这种情况下，发送器可以连续发送消息的多个（例如，三个）实例，由适合于应用程序或由应用程序指定的延迟分隔。例如，在设备重置后发送刷新指令时，可能会调用此过程。预期接收器将使用MI检测重复消息。
G-ACh Advertisement Protocol message reception SHALL operate on a per-data-channel basis and be configurable by the operator accordingly.
G-ACh广告协议消息接收应在每个数据通道的基础上运行，并由运营商进行相应配置。
Upon receiving a G-ACh Advertisement Protocol message that contains data for some application X, the receiver determines whether it can interpret X-data. If it cannot, then the receiver MAY retain this data for the number of seconds specified by the Lifetime field; although it cannot parse this data, it may still be of use to the operator.
在接收到包含某个应用程序X的数据的G-ACh播发协议消息后，接收器确定是否可以解释X数据。如果不能，则接收器可将该数据保留由寿命字段指定的秒数；虽然它无法解析此数据，但它可能仍然对操作员有用。
If the receiver can interpret X-data, then it processes the data objects accordingly, retaining the data associated with those that represent static data for the number of seconds specified by the Lifetime field. If the Lifetime is zero, such data is immediately marked as expired, and, if no TLVs are specified, all data associated with previously received TLVs is marked as expired (Section 3). If one of the received TLV objects has the same Type as a previously received TLV, then the data from the new object SHALL replace the data associated with that Type unless the X specification dictates a different behavior.
如果接收器可以解释X数据，那么它会相应地处理数据对象，将与表示静态数据的数据关联的数据保留在寿命字段指定的秒数内。如果生存期为零，则此类数据立即标记为过期，如果未指定TLV，则与先前接收的TLV相关的所有数据都标记为过期（第3节）。如果其中一个接收到的TLV对象具有与先前接收到的TLV相同的类型，则来自新对象的数据应替换与该类型相关联的数据，除非X规范规定了不同的行为。
The received data is made available to local applications that require it and are locally authorized to view it. The method for doing this is local to the receiver and outside the scope of this document.
接收到的数据可供需要它的本地应用程序使用，并且本地授权查看它。这样做的方法对于接收者来说是本地的，不在本文档的范围之内。
The receiver MAY make use of the application data contained in a GAP message to perform some level of auto-configuration, for example, if the application is an OAM protocol. The application SHOULD, however, take care to prevent cases of oscillation resulting from each endpoint attempting to adjust its configuration to match the other. Any such auto-configuration based on GAP information MUST be disabled by default.
例如，如果应用是OAM协议，则接收机可以利用包含在间隙消息中的应用数据来执行某种级别的自动配置。但是，应用程序应该注意防止由于每个端点试图调整其配置以匹配另一个端点而导致的振荡情况。默认情况下，必须禁用基于间隙信息的任何此类自动配置。
The MI may be used to detect and discard duplicate messages.
MI可用于检测和丢弃重复消息。
The GAP provides a means of authenticating messages and ensuring their integrity. This is accomplished by attaching a GAP Authentication TLV and including, in the Authentication Data field, the output of a cryptographic hash function (known as a Message Authentication Code (MAC)), the input to which is the message together with a secret key known only to the sender and receiver. Upon receipt of the message, the receiver computes the same MAC and compares the result with the MAC in the message; if the MACs are not equal, the message is discarded. Use of GAP message authentication is RECOMMENDED.
GAP提供了一种验证消息并确保其完整性的方法。这是通过附加GAP认证TLV并在认证数据字段中包括加密散列函数（称为消息认证码（MAC））的输出来实现的，该加密散列函数的输入是消息以及仅对发送方和接收方已知的密钥。在接收到消息时，接收器计算相同的MAC，并将结果与消息中的MAC进行比较；如果MAC不相等，则丢弃该消息。建议使用GAP消息身份验证。
The remainder of this section gives the details of this procedure, which is based on the procedures for generic cryptographic authentication for the Intermediate System to Intermediate System (IS-IS) routing protocol as described in [RFC5310].
本节的其余部分给出了该程序的详细信息，该程序基于[RFC5310]中所述的中间系统到中间系统（is-is）路由协议的通用加密身份验证程序。
An Authentication Key Identifier (Key ID) is a 16-bit tag shared by the sender and receiver that identifies a set of authentication parameters. These parameters are not sent over the wire; they are assumed to be associated, on each node, with the Key ID by external means, such as via explicit operator configuration or a separate key-exchange protocol. Multiple Key IDs may be active on the sending and receiving nodes simultaneously, in which case the sender locally selects a Key ID from this set to use in an outbound message. This capability facilitates key migration in the network.
身份验证密钥标识符（密钥ID）是发送方和接收方共享的16位标记，用于标识一组身份验证参数。这些参数不是通过导线发送的；假定它们在每个节点上通过外部手段（例如通过显式操作员配置或单独的密钥交换协议）与密钥ID相关联。多个密钥ID可能同时在发送和接收节点上处于活动状态，在这种情况下，发送方从该集合中本地选择一个密钥ID以用于出站消息。此功能有助于在网络中进行密钥迁移。
The parameters associated with a Key ID are:
与密钥ID关联的参数包括：
o Authentication Algorithm: This signifies the authentication algorithm to use to generate or interpret authentication data. At present, the following values MAY be supported: HMAC-SHA-1, HMAC-SHA-256. HMAC-SHA-1 MUST be supported.
o 身份验证算法：这表示用于生成或解释身份验证数据的身份验证算法。目前，可能支持以下值：HMAC-SHA-1、HMAC-SHA-256。必须支持HMAC-SHA-1。
o Authentication Keystring: A secret octet string that forms the basis for the cryptographic key used by the Authentication Algorithm. It SHOULD NOT be a human-memorable string. Implementations MUST be able to use random binary values of the appropriate length as a keystring.
o 身份验证密钥串：构成身份验证算法使用的加密密钥基础的秘密八位组字符串。它不应该是人类记忆中的弦。实现必须能够使用适当长度的随机二进制值作为键串。
Implementers SHOULD consider the use of [RFC7210] for key management. If used, authenticated information sent over the GAP MUST only considered valid if it was sent during the Keying and Authentication for Routing Protocols (KARP) interval between SendLifetimeStart and SendLifeTimeEnd. However, if the GAP TLV used to send it expires before the KARP SendLifetimeStart, then information is never used; if it expires before KARP SendNotAfter, the key becomes invalid on expiry of the GAP TLV.
实施者应该考虑使用[RCF7210]进行密钥管理。如果使用，则通过GAP发送的经过身份验证的信息必须仅在SendLifetimeStart和SendLifeTimeEnd之间的路由协议密钥和身份验证（KARP）间隔期间发送时才视为有效。但是，如果用于发送的GAP TLV在KARP SendLifetimeStart之前过期，则永远不会使用该信息；如果密钥在KARP SendNotAfter之前过期，则密钥在GAP TLV过期时失效。
At the time of this writing, mechanisms for dynamic key management in the absence of IP are not available. Key management in such environments therefore needs to take place via the equipment management system or some other out-of-band service. The MPLS layer in a network is normally isolated from direct access by users and thus is a relatively protected environment. Therefore, key turnover is expected to be a relatively infrequent event.
在撰写本文时，没有在没有IP的情况下进行动态密钥管理的机制。因此，此类环境中的密钥管理需要通过设备管理系统或其他带外服务进行。网络中的MPLS层通常与用户的直接访问隔离，因此是一个相对受保护的环境。因此，关键营业额预计将是一个相对罕见的事件。
The authentication process for GAP messages is straightforward. First, a Key ID is associated on both the sending and receiving nodes with a set of authentication parameters. Following this, when the sender generates a GAP message, it sets the Key ID field of the GAP Authentication TLV accordingly. (The length of the Authentication Data field is also known at this point because it is a function of the Authentication Algorithm.) The sender then computes a MAC for the message as described in Section 6.3 and fills the Authentication Data field of the GAP Authentication TLV with the MAC, overwriting the zeros used in computation. The message is then sent.
GAP消息的身份验证过程非常简单。首先，在发送和接收节点上将密钥ID与一组认证参数相关联。接下来，当发送方生成GAP消息时，它会相应地设置GAP身份验证TLV的密钥ID字段。（此时认证数据字段的长度也是已知的，因为它是认证算法的一个函数。）然后，发送方按照第6.3节所述计算消息的MAC，并用MAC填充GAP认证TLV的认证数据字段，覆盖计算中使用的零。然后发送消息。
When the message is received, the receiver computes a MAC for it as described below, again setting the Authentication Data field of the GAP Authentication TLV to all zeros before computing the MAC. The receiver compares its computed MAC to the MAC received in the Authentication Data field. If the two MACs are equal, authentication of the message is considered to have succeeded; otherwise, it is considered to have failed.
当接收到消息时，接收机如下所述为其计算MAC，在计算MAC之前再次将GAP认证TLV的认证数据字段设置为全零。接收器将其计算的MAC与在认证数据字段中接收的MAC进行比较。如果两个MAC相等，则认为消息的身份验证已成功；否则，它将被视为失败。
This process suffices to ensure the authenticity and integrity of messages but is still vulnerable to a replay attack, in which a third party captures a message and sends it on to the receiver at some later time. The GAP message header contains a Timestamp field, which
此过程足以确保消息的真实性和完整性，但仍然容易受到重播攻击，即第三方捕获消息并在稍后某个时间将其发送给接收方。GAP消息头包含一个时间戳字段，该字段
can be used to protect against replay attacks. To achieve this protection, the receiver checks that the time recorded in the Timestamp field of a received and authenticated GAP message corresponds to the current time, within a reasonable tolerance that allows for message propagation delay, and it accepts or rejects the message accordingly. Clock corrections SHOULD be monotonic to avoid replay attacks, unless operator intervention overrides the monotonic configuration setting to achieve a faster convergence with current time.
可用于防止重播攻击。为了实现此保护，接收器检查记录在已接收和已认证间隙消息的时间戳字段中的时间是否与当前时间相对应，在允许消息传播延迟的合理容差内，并且接收器相应地接受或拒绝消息。时钟校正应该是单调的，以避免重播攻击，除非操作员干预覆盖单调配置设置以实现与当前时间的更快收敛。
If the clocks of the sender and receiver are not synchronized with one another, then the receiver must perform the replay check against its best estimate of the current time according to the sender's clock. The timestamps that appear in GAP messages can be used to infer the approximate clock offsets of senders, and, while this does not yield high-precision clock synchronization, it suffices for purposes of the replay check with an appropriately chosen tolerance.
如果发送方和接收方的时钟彼此不同步，则接收方必须根据发送方的时钟对其当前时间的最佳估计值执行重播检查。出现在间隙消息中的时间戳可用于推断发送方的近似时钟偏移量，并且，虽然这不会产生高精度时钟同步，但对于具有适当选择的容差的重播检查而言，它就足够了。
The HMAC procedure described in [RFC2104] is used to compute the MAC.
[RFC2104]中描述的HMAC程序用于计算MAC。
The Authentication Data field of the GAP Authentication TLV is set to all zeros. The MAC is then computed over the entire GAP message as shown in Figure 1.
GAP认证TLV的认证数据字段设置为全零。然后在整个GAP消息上计算MAC，如图1所示。
Where there is less data than is needed for the MAC computation, a value of zero MUST be used.
如果数据少于MAC计算所需的数据，则必须使用零值。
The length of the Authentication Data field is always less than or equal to the message digest size of the specific hash function that is being used. However, the implementer needs to consider that although MAC truncation decreases the size of the message, it results in a corresponding reduction in the strength of the assurance provided.
身份验证数据字段的长度始终小于或等于正在使用的特定哈希函数的消息摘要大小。然而，实现者需要考虑，虽然MAC截断会减小消息的大小，但会导致所提供的保证强度的相应降低。
MAC truncation is NOT RECOMMENDED.
不建议使用MAC截断。
When the GAP is used to support device discovery on a data link, GAP messages must be sent in such a way that they can be received by other listeners on the link without the sender first knowing the link-layer addresses of the listeners. In short, they must be multicast. Considerations for multicast MPLS encapsulation are discussed in [RFC5332]. For example, Section 8 of [RFC5332] describes how destination Ethernet MAC addresses are selected for multicast MPLS packets. Since a GAP packet transmitted over a data
当GAP用于支持数据链路上的设备发现时，发送GAP消息的方式必须确保链路上的其他侦听器可以接收到GAP消息，而发送者不必首先知道侦听器的链路层地址。简而言之，它们必须是多播的。[RFC5332]中讨论了多播MPLS封装的注意事项。例如，[RFC5332]的第8节描述了如何为多播MPLS数据包选择目标以太网MAC地址。由于间隙数据包是通过数据传输的
link contains just one label, the G-ACh Label (GAL) with label value 13, the correct destination Ethernet address for frames carrying GAP packets intended for device discovery, according to these selection procedures, is 01-00-5e-80-00-0d.
链路仅包含一个标签，即标签值为13的G-ACh标签（GAL），根据这些选择程序，承载用于设备发现的间隙数据包的帧的正确目标以太网地址为01-00-5e-80-00-0d。
The data sent and received by this protocol MUST be made accessible for inspection by network operators, and where local configuration is updated by the received information, it MUST be clear why the configured value has been changed. This allows the operator to determine the operational parameters currently in use and to understand when local configuration has been superseded by inbound parameters received from its peer.
通过该协议发送和接收的数据必须可供网络运营商检查，如果本地配置由接收到的信息更新，则必须清楚配置值更改的原因。这允许操作员确定当前使用的操作参数，并了解本地配置何时被从对等方接收的入站参数取代。
In the event of a system restart, any GAP application data and peer state data that has been retained as a consequence of prior advertisements from GAP peers MUST be discarded; this prevents incorrect operation on the basis of stale data.
在系统重新启动的情况下，必须丢弃由于来自GAP对等方的先前公告而保留的任何GAP应用程序数据和对等方状态数据；这可以防止基于过时数据的错误操作。
All GAP applications MUST be disabled by default and need to be enabled by the operator if required.
默认情况下，必须禁用所有间隙应用程序，如果需要，操作员需要启用这些应用程序。
G-ACh Advertisement Protocol messages contain information about the sending device and its configuration, which is sent in cleartext over the wire. If an unauthorized third party gains access to the MPLS data plane or the lower network layers between the sender and receiver, it can observe this information. In general, however, the information contained in GAP messages is no more sensitive than that contained in other protocol messages, such as routing updates, which are commonly sent in cleartext. No attempt is therefore made to guarantee confidentiality of GAP messages. Therefore, the GAP MUST NOT be used to send TLVs in cleartext where the value concerned requires confidentiality, for example, GAP or application TLVs containing 'bare' cryptographic keying material. Applications that require confidentiality will need to implement a suitable confidentiality method.
G-ACh广告协议消息包含有关发送设备及其配置的信息，这些信息以明文形式通过有线发送。如果未经授权的第三方获得了对MPLS数据平面或发送方和接收方之间的较低网络层的访问权，则可以观察此信息。但是，一般来说，GAP消息中包含的信息并不比其他协议消息（例如路由更新）中包含的信息更敏感，后者通常以明文形式发送。因此，不会试图保证GAP消息的机密性。因此，在相关值需要保密的情况下，GAP不得用于以明文形式发送TLV，例如，GAP或包含“裸”加密密钥材料的应用程序TLV。需要保密的应用程序需要实现适当的保密方法。
A more significant potential threat is the transmission of GAP messages by unauthorized sources, or the unauthorized manipulation of messages in transit; this can disrupt the information receivers hold about legitimate senders. To protect against this threat, message authentication procedures (specified in Section 6) enable receivers to ensure the authenticity and integrity of GAP messages. These
更重要的潜在威胁是未经授权的来源传输GAP消息，或在传输过程中未经授权操纵消息；这可能会破坏接收者掌握的有关合法发送者的信息。为了防止这种威胁，消息身份验证程序（第6节中规定）使接收方能够确保GAP消息的真实性和完整性。这些
procedures include the means to protect against replay attacks in which a third party captures a legitimate message and "replays" it to a receiver at some later time.
程序包括防止重放攻击的方法，其中第三方捕获合法消息并在稍后某个时间将其“重放”给接收方。
IANA has allocated an entry in the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry for the "G-ACh Advertisement Protocol", as follows:
IANA已在“MPLS通用关联通道（G-ACh）类型（包括伪线关联通道类型）”注册表中为“G-ACh广告协议”分配了一个条目，如下所示：
Value Description Reference
------ ---------------------------- ---------
0x0059 G-ACh Advertisement Protocol This RFC
Value Description Reference
------ ---------------------------- ---------
0x0059 G-ACh Advertisement Protocol This RFC
The reader should note that the "TLV Follows" column in the registry has been deleted [RFC7026].
读者应注意，注册表中的“TLV Follows”列已被删除[RFC7026]。
IANA has allocated three entries from the Standards Track range in the "Address Family Numbers" registry for MPLS-TP Section, LSP, and Pseudowire endpoint identifiers, per Section 4.1. The allocations are:
IANA已根据第4.1节从“地址系列号”注册表中的标准轨道范围为MPLS-TP段、LSP和伪线端点标识符分配了三个条目。拨款如下：
Number Description Reference
------ -------------------------------------- ---------
26 MPLS-TP Section Endpoint Identifier This RFC
27 MPLS-TP LSP Endpoint Identifier This RFC
28 MPLS-TP Pseudowire Endpoint Identifier This RFC
Number Description Reference
------ -------------------------------------- ---------
26 MPLS-TP Section Endpoint Identifier This RFC
27 MPLS-TP LSP Endpoint Identifier This RFC
28 MPLS-TP Pseudowire Endpoint Identifier This RFC
IANA has created a new registry, "G-ACh Advertisement Protocol Application Registry" in the "Generic Associated Channel (G-ACh) Parameters" registry, with fields and initial allocations as follows:
IANA在“通用关联通道（G-ACh）参数”注册表中创建了一个新的注册表“G-ACh广告协议应用程序注册表”，其字段和初始分配如下：
Application ID Description Reference
-------------- ---------------------------- ---------
0x0000 G-ACh Advertisement Protocol This RFC
Application ID Description Reference
-------------- ---------------------------- ---------
0x0000 G-ACh Advertisement Protocol This RFC
The range of the Application ID field is 0x0000 - 0xFFFF.
应用程序ID字段的范围为0x0000-0xFFFF。
The allocation policy for this registry is IETF Review.
此注册表的分配策略为IETF Review。
IANA has created a new registry, "G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the "Generic Associated Channel (G-ACh) Parameters" registry, with fields and initial allocations as follows:
IANA在“通用关联通道（G-ACh）参数”注册表中创建了一个新的注册表“G-ACh播发协议：GAP TLV对象（应用程序ID 0）”，其字段和初始分配如下：
Type Name Type ID Reference
------------------ ------- ---------
Source Address 0 This RFC
GAP Request 1 This RFC
GAP Flush 2 This RFC
GAP Suppress 3 This RFC
GAP Authentication 4 This RFC
Type Name Type ID Reference
------------------ ------- ---------
Source Address 0 This RFC
GAP Request 1 This RFC
GAP Flush 2 This RFC
GAP Suppress 3 This RFC
GAP Authentication 4 This RFC
The range of the Type ID field is 0 - 255.
类型ID字段的范围为0-255。
The allocation policy for this registry is IETF Review.
此注册表的分配策略为IETF Review。
We thank Adrian Farrel for his valuable review comments on this document.
我们感谢阿德里安·法雷尔对本文件的宝贵评论。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Vigoureux，M.，和S.Bryant，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428]Allan，D.，Swallow Ed.，G.，和J.Drake Ed.，“MPLS传输配置文件的主动连接验证、连续性检查和远程缺陷指示”，RFC 6428，2011年11月。
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, April 2014.
[RFC7210]Housley，R.，Polk，T.，Hartman，S.，和D.Zhang，“长寿命对称加密密钥数据库”，RFC 72102014年4月。
[LLDP] IEEE, "Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, September 2009.
[LLDP]IEEE，“站点和媒体访问控制连接发现”，IEEE 802.1AB，2009年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[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月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月。
[RFC7026] Farrel, A. and S. Bryant, "Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel", RFC 7026, September 2013.
[RFC7026]Farrel，A.和S.Bryant，“将TLV从MPLS通用关联信道的关联信道头中退役”，RFC 7026，2013年9月。
[RFC7213] Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop Ethernet Addressing", RFC 7213, June 2014.
[RFC7213]Frost，D.，Bryant，S.，和M.Bocci，“MPLS-TP下一跳以太网寻址”，RFC 7213，2014年6月。
Authors' Addresses
作者地址
Dan Frost Blue Sun
丹弗罗斯特蓝色太阳
EMail: frost@mm.st
EMail: frost@mm.st
Stewart Bryant Cisco Systems
思科系统公司
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Matthew Bocci Alcatel-Lucent
马修·博奇·阿尔卡特·朗讯
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com