[要約] RFC 7212は、MPLS Generic Associated Channel (G-ACh) Advertisement Protocolに関する規格です。このプロトコルの目的は、MPLSネットワーク内でG-AChを広告するための仕組みを提供することです。
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 Generic Associated Channel（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 Generic Associated Channel（G-ACh）は、Label Switched Path（LSP）、疑似配線、またはさまざまなプロトコルが流れるセクション（リンク）に関連付けられた補助論理データチャネルを提供します。これらのプロトコルは、プライマリデータチャネルに関連付けられた運用、管理、および保守（OAM）メカニズムを提供するために一般的に使用されます。このドキュメントでは、LSP、疑似配線、またはセクションのエンドポイントが他のエンドポイントにその機能と構成パラメータ、またはその他のアプリケーション固有の情報を通知するための簡単な手順を説明しています。この情報は、受信者がローカル設定を検証または調整するために使用したり、ネットワークオペレーターが診断目的で使用したりできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 Generic Associated Channel（G-ACh）は、[RFC5586]で定義および説明されています。これは、さまざまなプロトコルが流れる可能性のある補助論理データチャネルを提供します。このような各データチャネルは、MPLSラベルスイッチドパス（LSP）、疑似配線、またはセクション（リンク）に関連付けられています。 G-AChと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 Advertisement Protocol（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.
ネットワークでは、ノードが隣接ノード、つまりノードがリンクしているノードについての一般的な情報を持っていると、ネットワークで頻繁に役立ちます。これにより、最低でも、このノードにアクセスできる人間のオペレーターまたは管理アプリケーションは、このノードがどの隣接ノードを参照できるかを判別できます。これは、接続の問題をトラブルシューティングするときに役立ちます。 「隣接認識プロトコル」の典型的な例は、Link Layer Discovery Protocol [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.
IPもサポートしないMPLSトランスポートプロファイル（MPLS-TP）[RFC5921]に基づくネットワークでは、隣接するMPLSノードのイーサネットアドレスを決定するために使用される通常のプロトコル（アドレス解決プロトコル[RFC0826]やIPバージョンなど） 6近隣探索[RFC4861]は使用できません。 G-AChアドバタイズメントプロトコルの1つの考えられる使用法は、IP機能がない[RFC7213] MPLS-TPノードのイーサネットメディアアクセス制御アドレスを発見することです。ただし、イーサネットリンクを介して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または疑似配線に存在するため、GAPメッセージはリモートLSPまたは疑似配線エンドポイントと交換できます。 GAPメッセージの内容は簡単に拡張でき、リンク、LSP、または疑似配線によって接続されたMPLS LSRに役立つ可能性のあるあらゆる種類の情報を含めることができます。たとえば、OAM機能をG-AChに依存しているネットワークでは、GAPメッセージを使用して、隣接する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
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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メッセージを送信します。 GAPメッセージのペイロードは、アプリケーションごとに編成されたType-Length-Value（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.
各GAPメッセージには、複数のアプリケーションのデータを含めることができます。送信者は、前のメッセージで送信された他のアプリケーションのデータに影響を与えることなく、アプリケーションのサブセットのデータを更新する対象の更新を送信できます。 GAPメッセージは、受信した順序で処理されます。
For example, a GAP message might be sent containing the following data:
たとえば、次のデータを含むGAPメッセージが送信される場合があります。
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はGAP TLVの例を参照しています。
A second message might then be sent containing:
次に、次の内容を含む2番目のメッセージが送信されます。
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.
2番目のメッセージを受信すると、受信者は最初のメッセージのB-TLV1を保持し、B-TLV7をそのBデータベースに追加します。新しいB-TLV3の処理方法は、Bがこのオブジェクトタイプに指定したルールによって異なります。このオブジェクトは古いオブジェクトを置き換えるか、何らかの方法でそれと組み合わせることができます。 2番目のメッセージは、アプリケーション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メッセージ経由で送信することを望む場合、それに応じてデータをフラグメント化するのはアプリケーションの責任です。 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.
GAPは、単方向チャネルで実行されるように設計されています。ただし、チャネルが双方向の場合、受信側から送信側への送信用に定義された多数のメッセージを使用することにより、通信を最適化できます。これらは最適化であり、プロトコル操作には必要ありません。
An Associated Channel Header (ACH) Channel Type has been allocated for the GAP as follows:
関連付けられたチャネルヘッダー（ACH）チャネルタイプは、次のようにGAPに割り当てられています。
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ヘッダーが続くことはありません（SHALL NOT）。
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メッセージは、固定ヘッダーと、それに続くGAPペイロードで構成されます。 GAPメッセージのペイロードは、1つ以上のブロック要素で構成されるアプリケーションデータブロック（ADB）です。各ブロック要素には、アプリケーション識別子、ライフタイム、およびそれが記述するアプリケーションの一連の0個以上の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.
不正なGAPメッセージは、エラーがログに記録される可能性がありますが、受信者によって破棄される必要があります。エラーがリモートでログに記録される場合は、適切な形式のレート制限を使用して、ネットワーク上で過剰なログメッセージが送信されるのを防ぐ必要があります（SHOULD）。
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):
次の図は、関連チャネルヘッダー（ACH）に続くG-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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット）：このメッセージの一意の識別子。曖昧さをなくすために、送信者は、それに関連付けられたすべてのADBが受信者によって期限切れになったと確信できるまで、特定のチャネルでMIを再利用してはなりません（MUST NOT）。このフィールドの唯一の目的は、メッセージがバーストした場合の重複検出です（セクション5.1）。
Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, as specified in Section 6 of [RFC5905].
タイムスタンプ：[RFC5905]のセクション6で指定されている64ビットのネットワークタイムプロトコル（NTP）送信タイムスタンプ。
An ADB consists of one or more elements of the following format:
ADBは、次の形式の1つ以上の要素で構成されています。
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を持つ複数のブロック要素が存在する場合があり、異なるアプリケーションIDを持つブロック要素も同じADBに存在する場合があります。存在する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の場合、ライフタイムは重要ではありません。 GAPメッセージの送信者は、Lifetimeフィールドをゼロに設定することでこれを示します。ライフタイムがゼロの場合、この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.
アプリケーションデータブロック要素の残りの部分は、セクション3.3で定義されたフォーマットを使用する0個以上のTLVオブジェクトのシーケンスで構成されます。
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.
ライフタイムフィールドは、その特定のコンテキストでのADB要素データのライフタイムを指定します。
GAP TLV objects use the following format:
GAP 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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レジストリを作成して、そのType値を追跡します。
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.
GAPメッセージにはチェックサムが含まれていません。メッセージの整合性の検証が必要な場合は、セクション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のADB要素がGAPメッセージに存在する場合、それは他の要素に先行しなければなりません。これは、Flushメッセージを正しく操作するために特に重要です（セクション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 GAPメッセージは、受信した順に処理する必要があります。
The Source Address object identifies the sending device and possibly the transmitting interface and the channel; it has the following format:
Source 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「アドレスファミリ番号」レジストリで割り当てられた値の1つに設定する必要があります。
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アドレスに設定する必要があります（SHOULD）。チャネルがリンクの場合、このアドレスは送信インターフェースのアドレスである必要があります（SHOULD）。
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メッセージに含めて、チャネルのエンドポイント識別子に設定する必要があります（SHOULD）。これらのチャネル識別子のフォーマットは、[RFC6428]のセクション3.5.1、3.5.2、および3.5.3に記載されているとおりである必要があります（これらのセクションに示されている最初のTypeおよびLengthフィールドを除く）。 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:
このオブジェクトは、即時のユニキャストGAPアップデートを送信者に送信するための受信者の送信者による要求です。長さフィールドがゼロの場合、これはすべてのアプリケーションの更新が要求されていることを示します。それ以外の場合、Valueフィールドは、更新が要求されるアプリケーションを、一連のアプリケーション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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要求メッセージを破棄する必要があります（SHOULD）。
For an Application ID 0x0000 GAP Request, it is meaningful to respond with the Source Address.
アプリケーションID 0x0000 GAP要求の場合、送信元アドレスで応答することは意味があります。
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はGAPの一部と見なされるため、保持する必要はありません。ただし、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.
このオブジェクトは、この（送信者、チャネル）ペアに関連付けられているすべてのアプリケーションのGAPデータをフラッシュするように受信者に指示します。これはnullオブジェクトです。つまり、その長さはゼロに設定されています。
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フラッシュ命令は、GAPフラッシュ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はGAPの一部と見なされるため、保持する必要はありません。ただし、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:
このオブジェクトは、指定された期間、現在のチャネルを介してトランスミッタへのGAPアップデートの送信を停止するようにレシーバに要求します。期間は、秒単位の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GAP Suppress TLV Format
図6：GAP抑制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のリストが空の場合、すべてのGAPメッセージの抑制が要求されます。それ以外の場合は、リストされているアプリケーションに関連する更新のみの抑制が要求されます。期間をゼロにすると、リストされているアプリケーションに対する既存の抑制要求がキャンセルされます。
This object makes sense only for point-to-point channels or when the sender is receiving unicast GAP updates.
このオブジェクトは、ポイントツーポイントチャネルの場合、または送信者がユニキャストGAPアップデートを受信している場合にのみ意味があります。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Advertisement Protocolメッセージの送信は、データチャネルごとに動作する必要があり（SHALL）、それに応じてオペレーターが設定できる必要があります。
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メッセージ送信がアクティブになる可能性があるため、メッセージ同期タイマーは、大きな同期メッセージバーストの可能性を減らすために、特定のインターフェイスでサポートされるチャネル全体でランダム化する必要があります（SHOULD）。
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.
Timestampフィールドは、このメッセージが送信される時間に設定する必要があります。
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.
各アプリケーションデータブロック要素のライフタイムフィールドは、このメッセージとアプリケーションに関連付けられたデータを保持するように受信者に通知する秒数に設定する必要があります（SHALL）。
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要素を更新する必要があります。更新時間は、有効期限が切れる前に少なくとも3つの更新が送信されるように設定する必要があります（SHOULD）。たとえば、ライフタイムが210秒に設定されている場合、更新は少なくとも60秒に1回送信される必要があります。
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.
送信者は、以前にセクション3で説明したように、ADB要素の有効期間をゼロに設定することにより、以前に送信されたデータを期限切れとしてマークする必要があることを通知できます。
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.
場合によっては、アプリケーションは、データの一部を配信するための追加の信頼性を必要とすることがあります。この場合、トランスミッタは、アプリケーションに適切な、またはアプリケーションによって指定された遅延で区切られた、メッセージのいくつかのインスタンス（3つなど）を連続して送信できます（MAY）。たとえば、このプロシージャは、デバイスのリセット後にフラッシュ命令を送信するときに呼び出される場合があります。受信者がMIを使用して重複メッセージを検出することが期待されています。
G-ACh Advertisement Protocol message reception SHALL operate on a per-data-channel basis and be configurable by the operator accordingly.
G-AChアドバタイズメントプロトコルメッセージの受信は、データチャネルごとに動作する必要があり（SHALL）、それに応じてオペレーターが設定できる必要があります。
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 Advertisement Protocolメッセージを受信すると、受信者はXデータを解釈できるかどうかを判断します。それができない場合、受信者は、Lifetimeフィールドで指定された秒数の間、このデータを保持してもよい（MAY）。このデータを解析することはできませんが、それでもオペレーターに役立つ場合があります。
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データを解釈できる場合は、それに応じてデータオブジェクトを処理し、Lifetimeフィールドで指定された秒数の間、静的データを表すデータに関連付けられたデータを保持します。ライフタイムがゼロの場合、そのようなデータはすぐに期限切れとしてマークされ、TLVが指定されていない場合は、以前に受信したTLVに関連付けられたすべてのデータが期限切れとしてマークされます（セクション3）。受信したTLVオブジェクトの1つが以前に受信したTLVと同じタイプである場合、新しいオブジェクトからのデータは、X仕様が異なる動作を指示しない限り、そのタイプに関連付けられたデータを置き換えるものとします（SHALL）。
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プロトコルである場合、受信者は、GAPメッセージに含まれているアプリケーションデータを利用して、あるレベルの自動構成を実行できます。ただし、アプリケーションは、各エンドポイントが他のエンドポイントと一致するように構成を調整しようとすることによって発生する発振のケースを防ぐように注意する必要があります。 GAP情報に基づくそのような自動設定は、デフォルトで無効にする必要があります。
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.
実装者は、鍵管理のための[RFC7210]の使用を検討する必要があります（SHOULD）。使用する場合、GAPを介して送信される認証情報は、SendLifetimeStartとSendLifeTimeEndの間のルーティングプロトコルのキーイングおよび認証（KARP）インターバル中に送信された場合にのみ有効と見なされなければなりません（MUST）。ただし、それを送信するために使用された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を計算し、GAP認証TLVの認証データフィールドに入力します。 MACでは、計算で使用されるゼロを上書きします。その後、メッセージが送信されます。
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と比較します。 2つの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 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.
このプロセスはメッセージの信頼性と整合性を保証するのに十分ですが、サードパーティがメッセージをキャプチャして後で受信者に送信するリプレイ攻撃に対して依然として脆弱です。 GAPメッセージヘッダーには、タイムスタンプフィールドが含まれています。これは、リプレイアタックから保護するために使用できます。この保護を実現するために、受信者は、受信および認証されたGAPメッセージのTimestampフィールドに記録された時間が現在の時間に対応していることを確認し、メッセージの伝播遅延を許容する妥当な許容範囲内で、それに応じてメッセージを受け入れるか拒否します。クロック修正は、オペレーターの介入が単調な構成設定をオーバーライドして現在の時間との収束を速くしない限り、リプレイアタックを回避するために単調である必要があります。
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.
送信側と受信側のクロックが互いに同期していない場合、受信側は、送信側のクロックに応じて現在時刻の最適な見積もりに対して再生チェックを実行する必要があります。 GAPメッセージに表示されるタイムスタンプは、送信者のおおよそのクロックオフセットを推測するために使用できます。これにより、高精度のクロック同期は得られませんが、適切に選択された許容範囲での再生チェックの目的には十分です。
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の認証データフィールドはすべてゼロに設定されます。次に、図1に示すように、GAPメッセージ全体でMACが計算されます。
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 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.
GAPを使用してデータリンクでのデバイス検出をサポートする場合、GAPメッセージは、送信者が最初にリスナーのリンク層アドレスを知らなくても、リンク上の他のリスナーが受信できるように送信する必要があります。つまり、マルチキャストである必要があります。マルチキャストMPLSカプセル化に関する考慮事項は、[RFC5332]で説明されています。たとえば、[RFC5332]のセクション8は、マルチキャストMPLSパケットに対して宛先イーサネットMACアドレスが選択される方法を説明しています。データリンクを介して送信されるGAPパケットにはラベルが1つだけ含まれているため、ラベル値13のG-AChラベル（GAL）は、これらの選択手順に従って、デバイス検出を目的としたGAPパケットを伝送するフレームの正しい宛先イーサネットアドレスは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.
すべてのGAPアプリケーションはデフォルトで無効にする必要があり、必要に応じてオペレーターが有効にする必要があります。
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 Advertisement Protocolメッセージには、送信デバイスとその構成に関する情報が含まれており、クリアテキストでネットワーク経由で送信されます。許可されていない第三者が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 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.
より重大な潜在的な脅威は、許可されていないソースによるGAPメッセージの送信、または送信中のメッセージの許可されていない操作です。これにより、受信者が正当な送信者について保持している情報が混乱する可能性があります。この脅威から保護するために、メッセージ認証手順（セクション6で指定）により、受信者はGAPメッセージの信頼性と整合性を確保できます。これらの手順には、第三者が正当なメッセージをキャプチャし、後で受信者に「リプレイ」するリプレイ攻撃から保護する手段が含まれます。
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 Generalized Associated Channel（G-ACh）Types（pseudowire Associated Channel Types）」レジストリに「G-ACh Advertisement Protocol」のエントリを次のように割り当てました。
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、および疑似配線エンドポイント識別子について、「アドレスファミリ番号」レジストリの標準トラック範囲から3つのエントリを割り当てました。割り当ては次のとおりです。
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は、「Generic Associated Channel（G-ACh）Parameters」レジストリに「G-ACh Advertisement Protocol Application Registry」という新しいレジストリを作成しました。フィールドと初期割り当ては次のとおりです。
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レビューです。
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は、「Generic Associated Channel（G-ACh）Parameters」レジストリに新しいレジストリ「G-ACh Advertisement Protocol：GAP TLV Objects（Application 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
The range of the Type ID field is 0 - 255.
タイプIDフィールドの範囲は0〜255です。
The allocation policy for this registry is IETF Review.
このレジストリの割り当てポリシーはIETFレビューです。
We thank Adrian Farrel for his valuable review comments on this document.
このドキュメントに対する貴重なレビューコメントを提供してくれたAdrian Farrelに感謝します。
[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：Keyed-Hashing for Message Authentication」、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 Generic Associated Channel」、RFC 5586、2009年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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年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]アラン、D。、スワローエド。 、G.、J。ドレイクエド。 、「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 7210、2014年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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T。およびC.ピグナタロ、「疑似配線仮想回線接続検証（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 Generic Cryptographic Authentication」、RFC 5310、2009年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 5884、2010年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、「A Transport Framework in MPLS in MPLS」、RFC 5921、2010年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 6291 、2011年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 6374、2011年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、「MPLS Generic Associated Channelの関連チャネルヘッダーからのTLVの廃止」、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 Next-Hop Ethernet Addressing」、RFC 7213、2014年6月。
Authors' Addresses
著者のアドレス
Dan Frost Blue Sun
ダンフロストブルーサン
EMail: frost@mm.st
Stewart Bryant Cisco Systems
Stewart Bryant Cisco Systems
EMail: stbryant@cisco.com
Matthew Bocci Alcatel-Lucent
マシュー・ボッチ・アルカテル・ルーセント
EMail: matthew.bocci@alcatel-lucent.com