[要約] RFC 7178は、TRILL（Transparent Interconnection of Lots of Links）プロトコルのRBridge Channelサポートに関するものです。このRFCの目的は、RBridge Channelを使用してTRILLネットワークの拡張性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7178 Huawei
Category: Standards Track V. Manral
ISSN: 2070-1721 Ionos Corp.
Y. Li
S. Aldrin
Huawei
D. Ward
Cisco
May 2014
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
多数のリンクの透過的な相互接続（TRILL）：RBridgeチャネルのサポート
Abstract
概要
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.
このドキュメントでは、ルーティングブリッジ（RBridge）間、およびRBridgeキャンパス内のRBridgeとエンドステーション間で、リンクの透過的相互接続（TRILL）の拡張機能を介して、双方向転送検出（BFD）メッセージなどのメッセージを送信するための一般的なチャネルメカニズムを指定します。プロトコル。
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/rfc7178.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7178で入手できます。
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 ....................................................3
1.1. RBridge Channel Requirements ...............................3
1.2. Relation to the MPLS Generic Associated Channel ............4
1.3. Terminology ................................................4
2. Inter-RBridge Channel Messages ..................................4
2.1. RBridge Channel Message Inner Frame ........................6
2.1.1. RBridge Channel Header ..............................6
2.1.2. Inner Ethernet Header ...............................8
2.1.3. Inner.VLAN Tag ......................................8
2.2. TRILL Header for RBridge Channel Messages ..................9
2.3. Ethernet Link Header and Trailer ..........................10
2.4. Special Transmission and Rate Considerations ..............10
3. Processing RBridge Channel TRILL Data Messages .................11
3.1. Processing the RBridge Channel Header .....................12
3.2. RBridge Channel Errors ....................................13
4. Native RBridge Channel Frames ..................................14
5. Indicating Support for RBridge Channel Protocols ...............16
6. Congestion Considerations ......................................16
7. Allocation Considerations ......................................17
7.1. IANA Considerations .......................................17
7.2. IEEE Registration Authority Considerations ................18
8. Security Considerations ........................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
10. Acknowledgments ...............................................20
RBridge campuses provide transparent least-cost forwarding using the Transparent Interconnection of Lots of Links (TRILL) protocol that builds on Intermediate System to Intermediate System (IS-IS) routing [IS-IS] [RFC1195] [RFC7176]. Devices that implement TRILL are called Routing Bridges (RBridges) or TRILL Switches. However, the TRILL base protocol standard [RFC6325] provides only for TRILL Data messages and TRILL IS-IS messages.
RBridgeキャンパスは、中間システム間ルーティング（IS-IS）ルーティング[IS-IS] [RFC1195] [RFC7176]に基づいて構築されるリンクの透過的相互接続（TRILL）プロトコルを使用して、透過的な最小コスト転送を提供します。 TRILLを実装するデバイスは、ルーティングブリッジ（RBridges）またはTRILLスイッチと呼ばれます。ただし、TRILLベースプロトコル標準[RFC6325]では、TRILLデータメッセージとTRILL IS-ISメッセージのみが提供されます。
This document specifies a general channel mechanism for the transmission of other messages within an RBridge campus, such as BFD [RFC5880] messages, (1) between RBridges and end stations that are directly connected on the same link and (2) between RBridges. This mechanism supports a requirement to be able to operate with minimal configuration.
このドキュメントでは、BFD [RFC5880]メッセージ、（1）同じリンクで直接接続されているRBridgeとエンドステーション間、および（2）RBridge間など、RBridgeキャンパス内の他のメッセージを送信するための一般的なチャネルメカニズムを指定します。このメカニズムは、最小限の構成で動作できるようにする要件をサポートします。
It is anticipated that various protocols operating at the TRILL layer will be desired in RBridge campuses. For example, there is a need for rapid-response continuity checking with a protocol such as BFD [RFC5880] [RFC5882] and for a variety of optional reporting.
TRILLレイヤーで動作するさまざまなプロトコルがRBridgeキャンパスで望まれることが予想されます。たとえば、BFD [RFC5880] [RFC5882]などのプロトコルを使用した高速応答の継続性チェックと、さまざまなオプションのレポートが必要です。
To avoid the requirement to design and specify a way to carry each such protocol, this document specifies a general channel for sending messages between RBridges in a campus at the TRILL level by extending the TRILL protocol. To accommodate a wide variety of protocols, this RBridge Channel facility accommodates all the regular modes of TRILL Data transmission including single- and multiple-hop unicast as well as VLAN-scoped multi-destination distribution.
このような各プロトコルを伝送する方法を設計および指定する要件を回避するために、このドキュメントでは、TRILLプロトコルを拡張して、キャンパス内のRBridge間でTRILLレベルのメッセージを送信するための一般的なチャネルを指定します。多種多様なプロトコルに対応するために、このRBridgeチャネルファシリティは、シングルおよびマルチホップユニキャストやVLANスコープのマルチ宛先配信を含む、TRILLデータ送信のすべての通常モードに対応します。
To minimize any unnecessary burden on transit RBridges and to provide a more realistic test of network continuity and the like, RBridge Channel messages are designed to look like TRILL Data frames and, in the case of multi-hop messages, can normally be handled by transit RBridges as if they were TRILL Data frames; however, to enable processing at transit RBridges when required by particular messages, they may optionally use the RBridge Channel Alert TRILL extended header flags [RFC7179] that causes a transit RBridge implementing the flag to more closely examine a flagged frame.
トランジットRBridgeへの不要な負担を最小限に抑え、ネットワークの継続性などのより現実的なテストを提供するために、RBridgeチャネルメッセージはTRILLデータフレームのように設計され、マルチホップメッセージの場合、通常トランジットで処理できます。それらがTRILLデータフレームであるかのようにRBridge。ただし、特定のメッセージで必要なときにトランジットRBridgeでの処理を有効にするために、オプションでRBridge Channel Alert TRILL拡張ヘッダーフラグ[RFC7179]を使用できます。これにより、フラグを実装するトランジットRBridgeがフラグ付きフレームをより詳細に検査します。
This document also specifies a format for sending RBridge Channel messages between RBridges and end stations that are directly connected over a link, in either direction, when provided for by the protocol involved. For the most part, this format is the same as the format that is encapsulated by TRILL Data for inter-RBridge Channel messages.
このドキュメントでは、RBridgeと、リンクを介して直接接続されているエンドステーションとの間で、関係するプロトコルで規定されている場合に、どちらの方向にもRBridgeチャネルメッセージを送信するためのフォーマットも規定しています。ほとんどの場合、この形式は、RBridge間チャネルメッセージのTRILLデータによってカプセル化される形式と同じです。
Each particular protocol using the RBridge Channel facility will likely use only a subset of the facilities specified herein.
RBridgeチャネルファシリティを使用する特定の各プロトコルは、ここで指定されたファシリティのサブセットのみを使用する可能性があります。
The RBridge Channel is similar to the MPLS Generic Associated Channel specified in [RFC5586]. Instead of using a special MPLS label to indicate a special channel message, an RBridge Channel message is indicated by a special multicast Inner.MacDA and inner Ethertype (see Section 2.1).
RBridgeチャネルは、[RFC5586]で指定されているMPLS Generic Associated Channelに似ています。特別なMPLSラベルを使用して特別なチャネルメッセージを示す代わりに、RBridge Channelメッセージは、特別なマルチキャストInner.MacDAおよび内部Ethertypeによって示されます（セクション2.1を参照）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terminology and acronyms of [RFC6325] are used in this document with the additions listed below.
このドキュメントでは、[RFC6325]の用語と頭字語を以下のリストに追加して使用します。
BFD - Bidirectional Forwarding Detection
BFD-双方向転送検出
CHV - Channel Header Version
CHV-チャネルヘッダーバージョン
MH - Multi-Hop
MH-マルチホップ
NA - Native
NA-ネイティブ
SL - Silent
SL-サイレント
Channel messages between RBridges are transmitted as TRILL Data frames. (For information on channel messages that can be transmitted between RBridges and end stations that are directly connected by a link, see Section 4.) Inter-RBridge Channel messages are identified as such by their Inner.MacDA, which is the All-Egress-RBridges multicast address, together with their inner Ethertype, which is the RBridge-Channel Ethertype. This Ethertype is part of and starts the RBridge Channel Header.
RBridge間のチャネルメッセージはTRILLデータフレームとして送信されます。 （リンクによって直接接続されているRBridgeとエンドステーションの間で送信できるチャネルメッセージについては、セクション4を参照してください。）RBridge間チャネルメッセージは、All-Egress-であるInner.MacDAによってそのように識別されます。 RBridgesは、RBridge-Channel Ethertypeである内部Ethertypeとともにアドレスをマルチキャストします。このEthertypeは、RBridgeチャネルヘッダーの一部であり、開始します。
The diagram below shows the overall structure of an RBridge Channel Message frame on a link between two RBridges:
次の図は、2つのRBridge間のリンク上のRBridgeチャネルメッセージフレームの全体的な構造を示しています。
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Link Header | Section 2.3 if Ethernet link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.2
+--------------------------------+
| RBridge Channel Header | Section 2.1.1
+--------------------------------+
| Protocol-Specific Payload | See specific channel protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
Figure 1: RBridge Channel Frame Structure
図1：RBridgeチャネルフレーム構造
Optionally, some channel messages may require examination of the frame by transit RBridges that support the RBridge Channel feature, to determine if they need to take any action. To indicate this, such messages use an RBridge Channel Alert extended TRILL Header flag as further described in Section 3 below.
オプションで、一部のチャネルメッセージでは、RBridgeチャネル機能をサポートするトランジットRBridgeによるフレームの検査が必要であり、アクションを実行する必要があるかどうかを判断する必要があります。これを示すために、そのようなメッセージは、以下のセクション3でさらに説明するように、RBridge Channel Alert拡張TRILLヘッダーフラグを使用します。
Sections 2.1 and 2.2 describe the inner frame and the TRILL Header for frames sent in an RBridge Channel. As always, the outer Link Header and Link Trailer are whatever is needed to get a TRILL Data frame to the next-hop RBridge, depending on the technology of the link, and can change with each hop for multi-hop messages. Section 2.3 describes the outer Link Header for Ethernet links, and Section 2.4 discusses some special considerations for the first hop transmission of RBridge Channel messages.
セクション2.1と2.2では、RBridgeチャネルで送信されるフレームの内部フレームとTRILLヘッダーについて説明します。いつものように、外側のリンクヘッダーとリンクトレーラーは、リンクのテクノロジーに応じて、次のホップのRBridgeにTRILLデータフレームを取得するために必要なものであり、マルチホップメッセージの各ホップで変更できます。 2.3節ではイーサネットリンクの外部リンクヘッダーについて説明し、2.4節ではRBridgeチャネルメッセージの最初のホップ送信に関するいくつかの特別な考慮事項について説明します。
Section 3 describes some details of RBridge Channel message processing. Section 4 provides the specifications for native RBridge Channel frames between RBridges and end stations that are directly connected over a link. Section 5 describes how support for RBridge Channel protocols is indicated. And Sections 6, 7, and 8 give congestion, allocation (IANA and IEEE), and security considerations respectively.
セクション3では、RBridgeチャネルメッセージ処理の詳細について説明します。セクション4では、リンクを介して直接接続されているRBridgeとエンドステーション間のネイティブRBridgeチャネルフレームの仕様を示します。セクション5では、RBridgeチャネルプロトコルのサポートがどのように示されるかについて説明します。また、セクション6、7、および8では、輻輳、割り当て（IANAおよびIEEE）、およびセキュリティに関する考慮事項をそれぞれ示します。
The encapsulated inner frame within an RBridge Channel message frame is as shown below.
RBridge Channelメッセージフレーム内のカプセル化された内部フレームは次のとおりです。
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
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype | Priority, DEI, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the RBridge Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Channel-Protocol-Specific Data
| ...
Figure 2: RBridge Channel Inner Frame Header Fields
図2：RBridgeチャネルの内部フレームヘッダーフィールド
The Channel-Protocol-Specific Data contains the information related to the specific channel protocol used in the channel message. Details of that data are outside the scope of this document, except in the case of the RBridge Channel Error protocol specified in Section 3.2.
チャネルプロトコル固有のデータには、チャネルメッセージで使用される特定のチャネルプロトコルに関連する情報が含まれています。セクション3.2で指定されているRBridge Channel Errorプロトコルの場合を除いて、そのデータの詳細はこのドキュメントの範囲外です。
As shown in Figure 2, the RBridge Channel Header starts with the RBridge-Channel Ethertype (see Section 7.2). Following that is a four-byte quantity with four sub-fields as follows:
図2に示すように、RBridgeチャネルヘッダーはRBridge-Channel Ethertypeで始まります（セクション7.2を参照）。その後に続くのは、次の4つのサブフィールドを持つ4バイトの数量です。
CHV: A 4-bit field that gives the RBridge Channel Header Version. This document specifies version zero.
CHV：RBridgeチャネルヘッダーバージョンを示す4ビットのフィールド。このドキュメントでは、バージョン0を指定しています。
Channel Protocol: A 12-bit unsigned integer that specifies the particular RBridge Channel protocol to which the message applies.
チャネルプロトコル：メッセージが適用される特定のRBridgeチャネルプロトコルを指定する12ビットの符号なし整数。
Flags: Provides 12 bits of flags as described below.
フラグ：以下で説明するように、12ビットのフラグを提供します。
ERR: A 4-bit unsigned integer used in connection with error reporting at the RBridge Channel level as described in Section 3.
ERR：セクション3で説明されているように、RBridgeチャネルレベルでのエラー報告に関連して使用される4ビットの符号なし整数。
The flag bits are numbered from 0 to 11 as shown below.
フラグビットには、次のように0〜11の番号が付けられています。
| 0 1 2 3 4 5 6 7 8 9 10 11|
+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: Channel Header Flag Bits
図3：チャネルヘッダーフラグビット
Bit 0: The SL or Silent bit, the high-order bit in network order. If it is a one, it suppresses RBridge Channel Error messages (see Section 3).
ビット0：SLまたはサイレントビット。ネットワーク順の上位ビット。 1の場合、RBridgeチャネルエラーメッセージを抑制します（セクション3を参照）。
Bit 1: The MH or Multi-Hop bit. It is used to inform the destination RBridge protocol that the message may be multi-hop (MH=1) or was intended to be one-hop only (MH=0).
ビット1：MHまたはマルチホップビット。これは、メッセージがマルチホップ（MH = 1）である可能性があること、または1ホップのみ（MH = 0）であることが意図されていたことを宛先RBridgeプロトコルに通知するために使用されます。
Bit 2: The NA or Native bit. It is used as described in Section 4.
ビット2：NAまたはネイティブビット。セクション4で説明されているように使用されます。
Reserved: Bits reserved for future specification that MUST be sent as zero and ignored on receipt.
予約済み：ゼロとして送信し、受信時に無視する必要がある将来の仕様のために予約されたビット。
The RBridge Channel Protocol field specifies the protocol that the channel message relates to. The initial defined value is listed below.
RBridge Channel Protocolフィールドは、チャネルメッセージが関連するプロトコルを指定します。初期定義値を以下に示します。
Protocol Name - Section of This Document
-------- -------------------------------
0x001 RBridge Channel Error - Section 3
IANA Considerations for RBridge Channel protocol numbers are provided in Section 7. These include provisions for Private Use protocol numbers. Because different uses of Private Use RBridge Channel protocol numbers may conflict, such use MUST be within a private network. It is the responsibility of the private network manager to avoid conflicting use of these code points and unacceptable burdens within the private network from their use.
RBridgeチャネルのプロトコル番号に関するIANAの考慮事項は、セクション7に記載されています。これらには、私的使用プロトコル番号の規定が含まれます。 Private Use RBridge Channelプロトコル番号の異なる使用は競合する可能性があるため、そのような使用はプライベートネットワーク内で行う必要があります。これらのコードポイントの使用の競合や、使用によるプライベートネットワーク内の許容できない負担を回避するのは、プライベートネットワークマネージャーの責任です。
The special Inner.MacDA is the All-Egress-RBridges multicast Media Access Control (MAC) address to signal that the frame is intended for the egress (decapsulating) RBridge itself (or the egress RBridges themselves if the frame is multi-destination). (This address is called the All-ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype indicates that the frame is an RBridge Channel message. The only other Ethertype currently specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame [RFC6325]. In the future, additional Ethertypes may be specified for use with the All-Egress-RBridges multicast address.
特別なInner.MacDAはAll-Egress-RBridgesマルチキャストメディアアクセスコントロール（MAC）アドレスで、フレームが出力（カプセル化解除）RBridge自体（またはフレームが複数の宛先の場合は出力RBridges）向けであることを通知します。 （このアドレスは、[RFC6325]ではAll-ESADI-RBridgesアドレスと呼ばれています。）RBridge-Channel Ethertypeは、フレームがRBridge Channelメッセージであることを示します。 All-Egress-RBridges Inner.MacDAで現在使用が指定されている他の唯一のEthertypeは、ESADIフレームを示すL2-IS-ISです[RFC6325]。将来的には、All-Egress-RBridgesマルチキャストアドレスで使用するために、追加のEthertypeが指定される可能性があります。
The RBridge originating the channel message selects the Inner.MacSA. The Inner.MacSA MUST be set by the originating RBridge to a MAC address unique within the campus owned by the originating RBridge. This MAC address can be considered, in effect, the MAC address of a virtual internal end station that handles the RBridge Channel frames originated by or destined for that RBridge. It MAY be the same as the Inner.MacSA used by the RBridge when it originates ESADI frames [RFC6325].
チャネルメッセージを発信するRBridgeは、Inner.MacSAを選択します。 Inner.MacSAは、発信RBridgeによって、発信RBridgeが所有するキャンパス内で一意のMACアドレスに設定する必要があります。このMACアドレスは、実質的には、そのRBridgeが発信または宛先とするRBridgeチャネルフレームを処理する仮想内部エンドステーションのMACアドレスと見なすことができます。 ESADIフレーム[RFC6325]を生成するときにRBridgeが使用するInner.MacSAと同じになる場合があります。
As with all frames formatted to be processed as a TRILL Data frame, an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 0x8100 or stacked tags is beyond the scope of this document but is an obvious extension.
TRILLデータフレームとして処理されるようにフォーマットされたすべてのフレームと同様に、Inner.VLANタグが存在します。 0x8100またはスタックタグ以外のVLANタグEthertypeの使用は、このドキュメントの範囲外ですが、明らかな拡張です。
Multi-destination RBridge Channel messages are, like all multi-destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that distribution tree pruning is in effect in the campus, such channel messages may only reach RBridges advertising that they have connectivity to that VLAN.
複数の宛先のRBridgeチャネルメッセージは、すべての複数の宛先のTRILLデータメッセージと同様に、VLANスコープであるため、Inner.VLAN IDは対象のVLANに設定する必要があります。キャンパス内で配信ツリーのプルーニングが有効である限り、そのようなチャネルメッセージは、そのVLANに接続していることを通知するRBridgeにのみ到達する可能性があります。
For channel messages sent as known unicast TRILL Data frames, the default value for the Inner.VLAN ID is VLAN 1, but particular RBridge Channel protocols MAY specify other values.
既知のユニキャストTRILLデータフレームとして送信されるチャネルメッセージの場合、Inner.VLAN IDのデフォルト値はVLAN 1ですが、特定のRBridgeチャネルプロトコルは他の値を指定できます（MAY）。
The Inner.VLAN also specifies a three-bit frame priority for which the following recommendations apply:
Inner.VLANは、次の推奨事項が適用される3ビットフレームの優先順位も指定します。
1. For one-hop channel messages critical to network connectivity, such as one-hop BFD for rapid link-failure detection in support of TRILL IS-IS, the RECOMMENDED priority is 7.
1. TRILL IS-ISをサポートする迅速なリンク障害検出のための1ホップBFDなど、ネットワーク接続に重要な1ホップチャネルメッセージの場合、推奨される優先度は7です。
2. For single and multi-hop unicast channel messages important to network operation but not critical for connectivity, the RECOMMENDED priority is 6.
2. シングルホップおよびマルチホップのユニキャストチャネルメッセージで、ネットワーク操作には重要であるが接続には重要ではない場合、推奨される優先度は6です。
3. For other unicast channel messages and all multi-destination channel messages, it is RECOMMENDED that the default priority zero be used. In any case, priorities higher than 5 SHOULD NOT be used for such frames.
3. 他のユニキャストチャネルメッセージおよびすべての複数宛先チャネルメッセージの場合、デフォルトの優先度ゼロを使用することをお勧めします。いずれの場合も、そのようなフレームには5より高い優先度を使用しないでください。
There is one additional bit in a VLAN tag value between the 12-bit VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI) [RFC7180]. It is RECOMMENDED that this bit be zero for the first two categories of channel messages listed immediately above. The setting of this bit for channel messages in the third category may be dependent on the channel protocol and no general recommendation is made for that case.
12ビットのVLAN IDと3ビットの優先度の間のVLANタグ値には、1つの追加ビットであるDrop Eligibility Indicator（DEI）[RFC7180]があります。上記のチャネルメッセージの最初の2つのカテゴリでは、このビットをゼロにすることをお勧めします。 3番目のカテゴリのチャネルメッセージに対するこのビットの設定は、チャネルプロトコルに依存する可能性があり、その場合の一般的な推奨事項はありません。
After the outer Link Header (that, for an Ethernet link, ends with the TRILL Ethertype) and before the encapsulated frame, the channel message's TRILL Header initially appears as follows:
外側のリンクヘッダー（イーサネットリンクの場合はTRILL Ethertypeで終わる）の後、カプセル化されたフレームの前に、チャネルメッセージのTRILLヘッダーは次のように表示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Op-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RBridge Channel TRILL Header Fields
図4：RBridgeチャネルのTRILLヘッダーフィールド
The TRILL Header version (V) MUST be zero; the R bits are reserved; the M bit is set appropriately as the channel message is to be forwarded as known destination unicast (M=0) or multi-destination (M=1), regardless of the fact that the Inner.MacDA is always the All-Egress-RBridges multicast address; and Op-Len is set appropriately for the length of the TRILL Header extensions area, if any, all as specified in [RFC6325].
TRILLヘッダーのバージョン（V）はゼロでなければなりません。 Rビットは予約されています。 Inner.MacDAが常にAll-Egress-RBridgesであるという事実に関係なく、チャネルメッセージが既知の宛先ユニキャスト（M = 0）または複数宛先（M = 1）として転送されるため、Mビットが適切に設定されます。マルチキャストアドレス;そしてOp-Lenは、もしあればTRILLヘッダー拡張領域の長さに対して適切に設定され、すべて[RFC6325]で指定されています。
When an RBridge Channel message is originated, the Hop Count field defaults to the maximum value, 0x3F, but particular RBridge Channel protocols MAY specify other values. For messages sent a known number of hops, such as one-hop messages or a two-hop self-addressed message intended to loop back through an immediate neighbor RBridge, setting the Hop Count field in the TRILL Header to the maximum value and checking its value on receipt provides an additional validity check as discussed in [RFC5082], where this type of field is referred to as "TTL" or "Hop Limit".
RBridge Channelメッセージが発信されると、ホップカウントフィールドはデフォルトで最大値0x3Fになりますが、特定のRBridge Channelプロトコルは他の値を指定する場合があります。既知のホップ数が送信されたメッセージの場合、1ホップメッセージや、直接隣接するRBridgeを介してループバックする2ホップの自己アドレス指定メッセージなど、TRILLヘッダーのホップカウントフィールドを最大値に設定し、その値をチェックします。 [RFC5082]で説明されているように、受信時の値は追加の有効性チェックを提供します。このタイプのフィールドは「TTL」または「ホップ制限」と呼ばれます。
The RBridge originating a channel message places a nickname that it holds in the Ingress Nickname field.
チャネルメッセージを発信するRBridgeは、保持するニックネームをIngress Nicknameフィールドに配置します。
There are several cases for the Egress Nickname field. If the channel message is multi-destination, then the Egress Nickname designates the distribution tree to use. If the channel message is a multi-hop unicast message, then the Egress Nickname is a nickname of the target RBridge; this includes the special case of a message intended to loop back from an immediate neighbor where the originator places one of its own nicknames in both the Ingress Nickname and Egress Nickname fields. If the channel message is a one-hop unicast message, there are two possibilities for the Egress Nickname.
Egress Nicknameフィールドにはいくつかのケースがあります。チャネルメッセージが複数の宛先である場合、出力ニックネームは使用する配信ツリーを指定します。チャネルメッセージがマルチホップユニキャストメッセージの場合、出力ニックネームはターゲットRBridgeのニックネームです。これには、発信者がIngress NicknameフィールドとEgress Nicknameフィールドの両方に独自のニックネームの1つを配置する、直接のネイバーからループバックすることを目的としたメッセージの特殊なケースが含まれます。チャネルメッセージが1ホップのユニキャストメッセージの場合、出力ニックネームには2つの可能性があります。
o The Egress Nickname can be set to a nickname of the target neighbor RBridge.
o 出力ニックネームは、ターゲットのネイバーRBridgeのニックネームに設定できます。
o The special nickname Any-RBridge may be used. RBridges supporting the RBridge Channel facility MUST recognize the Any-RBridge special nickname and accept TRILL Data frames having that value in the Egress Nickname field as being sent to them as the egress. Thus, for such RBridges, using this egress nickname guarantees processing by an immediate neighbor regardless of the state of nicknames.
o 特別なニックネームAny-RBridgeを使用できます。 RBridge Channel機能をサポートするRBridgeは、Any-RBridgeの特殊なニックネームを認識し、Egress Nicknameフィールドにその値を持つTRILLデータフレームを、出力として送信されるものとして受け入れる必要があります。したがって、そのようなRBridgeの場合、この出口ニックネームを使用すると、ニックネームの状態に関係なく、直接のネイバーによる処理が保証されます。
An RBridge Channel frame has the usual Link Header and Link Trailer for a TRILL Data frame depending on the type of link on which it is sent.
RBridge Channelフレームには、送信されるリンクのタイプに応じて、TRILLデータフレーム用の通常のリンクヘッダーとリンクトレーラーがあります。
For an Ethernet link [RFC6325], the Outer.MacSA is the MAC address of the port from which the frame is sent. The Outer.MacDA is the MAC address of the next-hop RBridge port for unicast RBridge Channel messages or the All-RBridges multicast address for multi-destination RBridge Channel messages. The Outer.VLAN tag specifies the designated VLAN for that hop, and the priority should be the same as in the Inner.VLAN tag; however, the output port may have been configured to strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. And the Link Trailer is the Ethernet FCS.
イーサネットリンク[RFC6325]の場合、Outer.MacSAは、フレームの送信元のポートのMACアドレスです。 Outer.MacDAは、ユニキャストRBridge ChannelメッセージのネクストホップRBridgeポートのMACアドレス、またはマルチ宛先RBridge ChannelメッセージのAll-RBridgesマルチキャストアドレスです。 Outer.VLANタグはそのホップに指定されたVLANを指定し、優先度はInner.VLANタグと同じにする必要があります。ただし、出力ポートがVLANタグを取り除くように構成されている場合があります。その場合、Outer.VLANタグはワイヤに表示されません。リンクトレーラーはイーサネットFCSです。
If a multi-hop RBridge Channel message is received by an RBridge, the criteria and method of forwarding it are the same as for any TRILL Data frame. If it is so forwarded, it will be on a link that was included in the routing topology because it was in the Report state as specified in [RFC7177].
マルチホップRBridge ChannelメッセージがRBridgeによって受信された場合、それを転送する基準と方法は、TRILLデータフレームの場合と同じです。転送された場合、[RFC7177]で指定されているようにReport状態であったため、ルーティングトポロジに含まれていたリンク上にあります。
However, special considerations apply to single-hop messages because, for some RBridge Channel protocols, it may be desirable to send RBridge Channel messages over a link that is not yet fully up. In particular, it is permissible, if specified by the particular channel protocol, for the source RBridge that has created an RBridge Channel message to attempt to transmit it to a next-hop RBridge when the link is in the Detect or 2-Way state, as specified in [RFC7177], as well as when it is in the Report state. Such messages can also be sent on point-to-point links that are not in the Up state.
ただし、一部のRBridge Channelプロトコルでは、まだ完全にアップしていないリンクを介してRBridge Channelメッセージを送信することが望ましい場合があるため、シングルホップメッセージには特別な考慮事項が適用されます。特に、特定のチャネルプロトコルで指定されている場合、リンクがDetectまたは2-Way状態のときに、RBridge Channelメッセージを作成したソースRBridgeがネクストホップRBridgeへの送信を試みることは許容されます。 [RFC7177]で指定されているとおり、およびReport状態のとき。このようなメッセージは、アップ状態ではないポイントツーポイントリンクで送信することもできます。
RBridge Channel messages represent a burden on the RBridges, and links in a campus and should be rate limited, especially if they are sent as high priority, multi-destination, or multi-hop frames or have an RBridge Channel Alert extended header flag set. See Section 6, "Congestion Considerations".
RBridgeチャネルメッセージはRBridgeとキャンパス内のリンクへの負担を表すものであり、特にそれらが高優先度、複数の宛先、またはマルチホップフレームとして送信される場合、またはRBridgeチャネルアラート拡張ヘッダーフラグが設定されている場合は、レートを制限する必要があります。セクション6「輻輳に関する考慮事項」を参照してください。
RBridge Channel TRILL Data messages are designed to look like and, to the extent practical, be forwarded as regular TRILL Data frames. On receiving a channel message, an RBridge performs the usual initial tests on the frame and makes the same forwarding and/or decapsulation decisions as for a regular TRILL Data frame [RFC6325] with the following exceptions for RBridges implementing the RBridge Channel facility:
RBridgeチャネルのTRILLデータメッセージは、通常のTRILLデータフレームのように見え、実用的な範囲で転送されるように設計されています。 RBridgeは、チャネルメッセージを受信すると、フレームに対して通常の初期テストを実行し、RBridge Channel機能を実装するRBridgeについて次の例外を除いて、通常のTRILLデータフレーム[RFC6325]と同じ転送またはカプセル化解除の決定を行います。
1. An RBridge implementing the RBridge Channel facility MUST recognize the Any-RBridge egress nickname in TRILL Data frames, decapsulating such frames if they meet other checks. (Such a frame cannot be a valid multi-destination frame because the Any-RBridge nickname is not a valid distribution tree root.)
1. RBridgeチャネルファシリティを実装するRBridgeは、TRILLデータフレーム内のAny-RBridge出口ニックネームを認識しなければならず、それらのフレームが他のチェックを満たす場合は、カプセル化を解除する必要があります。 （Any-RBridgeニックネームは有効な配布ツリーのルートではないため、このようなフレームは有効な複数宛先フレームにはなりません。）
2. If an RBridge Channel Alert extended header flag is set, then the RBridge MUST process the RBridge Channel message as described below even if it is not egressing the frame. If it is egressing the frame, then no additional processing beyond egress processing is needed even if an RBridge Channel Alert flag is set.
2. RBridge Channel Alert拡張ヘッダーフラグが設定されている場合、RBridgeは、フレームから出ていなくても、以下で説明するようにRBridge Channelメッセージを処理する必要があります。フレームから出力される場合、RBridge Channel Alertフラグが設定されていても、出力処理以外の追加の処理は必要ありません。
3. On decapsulation, the special Inner.MacDA value of All-Egress-RBridges MUST be recognized to trigger checking the Inner.Ethertype and processing as an RBridge Channel message if that Ethertype is RBridge-Channel.
3. カプセル化解除では、All-Egress-RBridgesの特別なInner.MacDA値を認識して、そのEthertypeがRBridge-Channelである場合にInner.EthertypeのチェックとRBridge Channelメッセージとしての処理をトリガーする必要があります。
RBridge Channel messages SHOULD only be sent to RBridges that advertise support for the channel protocol involved as described in Section 5.
RBridge Channelメッセージは、セクション5で説明されているように、関連するチャネルプロトコルのサポートを通知するRBridgeにのみ送信する必要があります（SHOULD）。
All RBridges supporting the RBridge Channel facility MUST recognize the RBridge-Channel inner Ethertype.
RBridge Channel機能をサポートするすべてのRBridgeは、RBridge-Channel内部Ethertypeを認識しなければなりません（MUST）。
Knowing that it has an RBridge Channel message, the egress RBridge, and any transit RBridge if an RBridge Channel Alert bit is set in the TRILL Header, looks at the CHV (RBridge Channel Header Version) and Channel Protocol fields.
TRILLヘッダーにRBridgeチャネルアラートビットが設定されている場合は、RBridgeチャネルメッセージ、出力RBridge、および通過RBridgeがあることを知って、CHV（RBridgeチャネルヘッダーバージョン）およびチャネルプロトコルフィールドを調べます。
If any of the following conditions occur at an egress RBridge, the frame is not processed, an error may be generated as specified in Section 3.2, and the frame is discarded. The behavior is the same if the frame is being processed at a transit RBridge because the RBridge Critical Channel Alert flag is set [RFC7179]. However, if these conditions are detected at a transit RBridge examining the message because the RBridge Non-critical Channel Alert flag is set [RFC7179] but the RBridge Critical Channel Alert flag is not set, no error is generated, and the frame is still forwarded normally.
出力RBridgeで次のいずれかの条件が発生した場合、フレームは処理されず、セクション3.2で指定されているようにエラーが生成され、フレームは破棄されます。 RBridge Critical Channel Alertフラグが設定されているため、トランジットRBridgeでフレームが処理されている場合の動作は同じです[RFC7179]。ただし、トランジットRBridgeでメッセージを調べてこれらの条件が検出された場合、RBridge Non-critical Channel Alertフラグが設定されていて[RFC7179]、RBridge Critical Channel Alertフラグが設定されていない場合、エラーは生成されず、フレームは引き続き転送されます。通常は。
Error Conditions:
エラー条件：
1. The Ethertype is not RBridge-Channel and not any other Ethertype known to the RBridge as usable with the All-Egress-RBridges Inner.MacDA, or the frame is so short that the Ethertype is truncated.
1. EthertypeがRBridge-Channelではなく、All-Egress-RBridges Inner.MacDAで使用できるとRBridgeが認識している他のどのEthertypeでもないか、フレームが短すぎてEthertypeが切り捨てられています。
2. The CHV field is non-zero, or the frame is so short that the version zero Channel Header is truncated.
2. CHVフィールドがゼロ以外であるか、フレームが非常に短いため、バージョン0のチャネルヘッダーが切り捨てられています。
3. The Channel Protocol field is a reserved value or a value unknown to the processing RBridge.
3. Channel Protocolフィールドは、予約済みの値、または処理中のRBridgeにとって不明な値です。
4. The ERR field is non-zero, and Channel Protocol is a value other than 0x001.
4. ERRフィールドはゼロ以外であり、チャネルプロトコルは0x001以外の値です。
5. The RBridge Channel Header NA flag is set to one, indicating that the frame should have been received as a native frame rather than a TRILL Data frame.
5. RBridge Channel Header NAフラグが1に設定され、フレームがTRILLデータフレームではなくネイティブフレームとして受信されている必要があることを示します。
If the CHV field and NA flag are zero and the processing RBridge recognizes the Channel Protocol value, it processes the message in accordance with that channel protocol. The processing model is as if the received frame starting with and including the TRILL Header is delivered to the Channel protocol along with a flag indicating whether this is (a) transit RBridge processing due to an RBridge Channel Alert flag being set or (b) egress processing.
CHVフィールドとNAフラグがゼロであり、処理中のRBridgeがチャネルプロトコル値を認識すると、そのチャネルプロトコルに従ってメッセージを処理します。処理モデルは、TRILLヘッダーで始まりTRILLヘッダーを含む受信フレームが、これが（a）RBridge Channel Alertフラグが設定されているためにトランジットRBridge処理であるか、（b）出力であるかを示すフラグとともにチャネルプロトコルに配信されるかのようです。処理。
Errors within a recognized Channel Protocol are handled by that channel protocol itself and do not produce RBridge Channel Error frames.
認識されたチャネルプロトコル内のエラーは、そのチャネルプロトコル自体によって処理され、RBridgeチャネルエラーフレームを生成しません。
A variety of problems at the RBridge Channel level cause the return of an RBridge Channel Error frame unless one of the following apply: (a) the "SL" (Silent) flag is a one in the channel message for which the problem was detected, (b) the processing is due to the RBridge Non-critical Channel Alert flag being set, (c) the frame in error appears, itself, to be an RBridge Channel Error frame (has a non-zero ERR field or a Channel Protocol of 0x001), or (d) the error is suppressed due to rate limiting.
RBridgeチャネルレベルでさまざまな問題が発生すると、以下のいずれかが当てはまらない限り、RBridgeチャネルエラーフレームが返されます。（a）「SL」（サイレント）フラグは、問題が検出されたチャネルメッセージのフラグです。 （b）処理はRBridge Non-critical Channel Alertフラグが設定されているためです。（c）エラーのあるフレーム自体がRBridge Channel Errorフレームであるように見えます（ゼロ以外のERRフィールドまたはChannel Protocolがあります） 0x001）、または（d）レート制限によりエラーが抑制されます。
An RBridge Channel Error frame is a multi-hop unicast RBridge Channel message with the Ingress Nickname set to a nickname of the RBridge detecting the error and the Egress Nickname set to the value of the Ingress Nickname in the channel message for which the error was detected. No per-hop transit processing is specified for such error frames, so the RBridge Channel Alert extended header flags SHOULD, if an extension is present, be set to zero. The SL and MH flags SHOULD be set to one; the NA flag MUST be zero; and the ERR field MUST be non-zero as described below. For the protocol-specific data area, an RBridge Channel Message Error frame has at least the first 256 bytes (or less if less are available) of the erroneous decapsulated channel message starting with the TRILL Header. (Note: The TRILL Header does not include the TRILL Ethertype that is part of the Link Header on Ethernet links.)
RBridge Channel Errorフレームは、Ingress Nicknameがエラーを検出したRBridgeのニックネームに設定され、Egress Nicknameがエラーが検出されたチャネルメッセージのIngress Nicknameの値に設定されたマルチホップユニキャストRBridge Channelメッセージです。 。このようなエラーフレームにはホップごとの中継処理が指定されていないため、拡張が存在する場合は、RBridge Channel Alert拡張ヘッダーフラグをゼロに設定する必要があります（SHOULD）。 SLフラグとMHフラグは1に設定する必要があります。 NAフラグはゼロでなければなりません。 ERRフィールドは、以下で説明するようにゼロ以外でなければなりません。プロトコル固有のデータ領域の場合、RBridgeチャネルメッセージエラーフレームには、TRILLヘッダーで始まる誤ったカプセル化されていないチャネルメッセージの少なくとも最初の256バイト（使用可能な場合はそれ以下）があります。 （注：TRILLヘッダーには、イーサネットリンクのリンクヘッダーの一部であるTRILL Ethertypeは含まれていません。）
The following values for ERR are specified:
ERRには次の値が指定されています。
ERR RBridge Channel Error Code Meaning
--- ----------------------------------
0 No error
1 Frame too short (truncated Ethertype or Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 Unassigned (see Section 7)
15 Reserved (see Note)
Note: Intended to be allocated by Standards Action for an error
code expansion feature when it appears likely that all
other available error codes are being allocated.
All RBridges implementing the RBridge Channel feature MUST recognize the RBridge Channel Error protocol value (0x001). They MUST NOT generate an RBridge Channel Error message in response to an RBridge Channel Error message, that is, a channel message with a protocol value of 0x001 or with a non-zero ERR field.
RBridge Channel機能を実装するすべてのRBridgeは、RBridge Channel Errorプロトコル値（0x001）を認識しなければなりません（MUST）。それらは、RBridge Channel Errorメッセージに応答してRBridge Channel Errorメッセージを生成してはいけません。つまり、プロトコル値が0x001であるか、ゼロ以外のERRフィールドを持つチャネルメッセージです。
Other sections of this document specify non-native RBridge Channel messages and their processing, that is, RBridge Channel messages formatted as TRILL Data frames and sent between RBridges. This section specifies the differences for native RBridge Channel messages.
このドキュメントの他のセクションでは、非ネイティブのRBridgeチャネルメッセージとその処理、つまりTRILLデータフレームとしてフォーマットされ、RBridge間で送信されるRBridgeチャネルメッセージを指定します。このセクションでは、ネイティブRBridgeチャネルメッセージの違いについて説明します。
If provided for by the channel protocol involved, native RBridge Channel messages may be sent between end stations and RBridges that are directly connected over a link, in either direction. On an Ethernet link, such native frames have the RBridge-Channel Ethertype and are like the encapsulated frame inside an RBridge Channel message except as follows:
関連するチャネルプロトコルによって提供される場合、ネイティブのRBridge Channelメッセージは、エンドステーションとリンクを介して直接接続されているRBridgeとの間で、どちらの方向にも送信できます。イーサネットリンクでは、このようなネイティブフレームにはRBridge-Channel Ethertypeがあり、以下の点を除いて、RBridgeチャネルメッセージ内のカプセル化されたフレームに似ています。
1. TRILL does not require the presence of a VLAN tag on such native RBridge Channel frames. However, port configuration, link characteristics, or the channel protocol involved may require such tagging.
1. TRILLでは、このようなネイティブRBridgeチャネルフレームにVLANタグが存在する必要はありません。ただし、ポート構成、リンク特性、または関連するチャネルプロトコルでは、このようなタグ付けが必要になる場合があります。
2. If the frame is unicast, the destination MAC address is the unicast MAC address of the RBridge or end-station port that is its intended destination. If the frame is multicast by an end station to all the RBridges on a link that support an RBridge Channel protocol using this transport, the destination MAC address is the All-Edge-RBridges multicast address (see Section 7). A native RBridge Channel frame received at an ingress RBridge is discarded if its destination MAC address is neither the unicast address of the port nor the multicast address All-Edge-RBridges. If the frame is multicast by an RBridge to all the devices that TRILL considers to be end stations on a link and that support an RBridge Channel protocol using this transport, the destination MAC address is the TRILL-End-Stations multicast address (see Section 7). A native RBridge Channel frame received at an end station is discarded if its destination MAC address is neither the unicast address of the port nor the multicast address TRILL-End-Stations.
2. フレームがユニキャストの場合、宛先MACアドレスは、目的の宛先であるRBridgeまたはエンドステーションポートのユニキャストMACアドレスです。端末がこのトランスポートを使用するRBridge Channelプロトコルをサポートするリンク上のすべてのRBridgeにマルチキャストされる場合、宛先MACアドレスはAll-Edge-RBridgesマルチキャストアドレスです（セクション7を参照）。入力RBridgeで受信されたネイティブRBridgeチャネルフレームは、その宛先MACアドレスがポートのユニキャストアドレスでもマルチキャストアドレスAll-Edge-RBridgesでもない場合は破棄されます。フレームがRBridgeによって、TRILLがリンク上のエンドステーションと見なし、このトランスポートを使用するRBridgeチャネルプロトコルをサポートするすべてのデバイスにマルチキャストされる場合、宛先MACアドレスはTRILL-End-Stationsマルチキャストアドレスです（セクション7を参照）。 ）。端末の宛先MACアドレスがポートのユニキャストアドレスでもマルチキャストアドレスTRILL-End-Stationでもない場合、端末で受信されたネイティブRBridgeチャネルフレームは破棄されます。
3. The RBridge-Channel outer Ethertype must be present. In the future, there may be other protocols using the All-Edge-RBridges and/or TRILL-End-Stations multicast addresses on native frames distinguished by different Ethertypes.
3. RBridgeチャネルの外部Ethertypeが存在する必要があります。将来的には、All-Edge-RBridgesやTRILL-End-Stationsマルチキャストアドレスを使用して、異なるEthertypeで区別されるネイティブフレームに他のプロトコルが存在する可能性があります。
4. The NA or Native bit in the RBridge Channel Header flags MUST be a one.
4. RBridgeチャネルヘッダーフラグのNAまたはネイティブビットは1でなければなりません。
5. There might be additional tags present between the Outer.MacDA, Outer.MacSA pair, and the RBridge-Channel Ethertype.
5. Outer.MacDA、Outer.MacSAペア、およびRBridge-Channel Ethertypeの間に追加のタグが存在する場合があります。
The RBridge Channel protocol number space for native RBridge Channel messages and TRILL Data formatted RBridge Channel messages is the same. If provided for by the channel protocol involved, the receipt of a native RBridge Channel frame MAY lead to the generation and transmission of one or more Inter-RBridge Channel frames. The decapsulation and processing of a TRILL Data RBridge Channel frame MAY, if provided for by the channel protocol involved, result in the sending of one or more native RBridge Channel frames to one or more end stations. Thus, there could be an RBridge Channel protocol that involved an RBridge Channel message sent (1) from an origin RBridge where the message is created, (2) through one or more transit RBridges, and (3) from a final RBridge as a native RBridge Channel message to an end station (or the reverse of such a three-part path); however, to do this, the RBridge Channel protocol involved must be implemented at the RBridge where the channel message is changed between a native frame and a TRILL Data format frame, and that RBridge must change the channel message itself, at a minimum complementing the NA flag in the Channel Header and making appropriate MAC address changes.
ネイティブRBridge ChannelメッセージとTRILL Data形式のRBridge ChannelメッセージのRBridge Channelプロトコル番号スペースは同じです。含まれるチャネルプロトコルによって提供される場合、ネイティブRBridgeチャネルフレームの受信は、1つまたは複数のInter-RBridgeチャネルフレームの生成と送信につながる場合があります。 TRILLデータRBridgeチャネルフレームのカプセル化解除と処理は、関連するチャネルプロトコルによって提供された場合、1つ以上のネイティブRBridgeチャネルフレームを1つ以上のエンドステーションに送信する可能性があります。したがって、（1）メッセージが作成された元のRBridgeから、（2）1つまたは複数のトランジットRBridgeを介して、および（3）ネイティブとして最後のRBridgeから送信されたRBridge Channelメッセージを含むRBridge Channelプロトコルが存在する可能性があります。端末へのRBridgeチャネルメッセージ（またはそのような3つの部分からなるパスの逆）。ただし、これを行うには、関連するRBridge ChannelプロトコルをRBridgeに実装する必要があります。RBridgeでは、チャネルメッセージがネイティブフレームとTRILLデータフォーマットフレームの間で変更され、そのRBridgeは、NAを最小限に補ってチャネルメッセージ自体を変更する必要があります。チャネルヘッダーのフラグを設定し、適切なMACアドレスを変更します。
An erroneous native channel message results in a native RBridge Channel Error message under the same conditions for which a TRILL Data RBridge Channel message would result in a TRILL Data RBridge Channel Error message. However, in a native RBridge Channel Error message, the NA flag MUST be one. Also, since there is no TRILL Header in native RBridge Channel protocol frames, the beginning part of the frame in which the error was detected that is included in native RBridge Channel Error frames starts with the RBridge Channel Header (including the RBridge-Channel Ethertype). The destination MAC address of such error messages is set to the source MAC address of the native RBridge Channel message that was in error.
誤ったネイティブチャネルメッセージは、TRILLデータRBridgeチャネルメッセージがTRILLデータRBridgeチャネルエラーメッセージを生成するのと同じ条件下で、ネイティブRBridgeチャネルエラーメッセージを生成します。ただし、ネイティブのRBridge Channel Errorメッセージでは、NAフラグは1でなければなりません。また、ネイティブRBridge ChannelプロトコルフレームにはTRILLヘッダーがないため、ネイティブRBridge Channel Errorフレームに含まれるエラーが検出されたフレームの最初の部分は、RBridge Channelヘッダー（RBridge-Channel Ethertypeを含む）で始まります。このようなエラーメッセージの宛先MACアドレスは、エラーが発生したネイティブRBridgeチャネルメッセージの送信元MACアドレスに設定されます。
There is no mechanism to stop end stations from directly exchanging native RBridge Channel messages, but such usage is beyond the scope of this document.
端末がネイティブのRBridge Channelメッセージを直接交換するのを停止するメカニズムはありませんが、そのような使用法はこのドキュメントの範囲を超えています。
Support for RBridge Channel protocols is indicated by the presence of one or more TLVs and/or sub-TLVs in an RBridge's Link State PDU (LSP) as documented in [RFC7176].
RBridge Channelプロトコルのサポートは、[RFC7176]で文書化されているように、RBridgeのリンク状態PDU（LSP）に1つ以上のTLVやサブTLVが存在することで示されます。
RBridge Channel protocols 0 and 0xFFF are reserved, and protocol 1, the RBridge Channel Error protocol, MUST be implemented as part of the RBridge Channel feature. Thus, if an RBridge supports the RBridge Channel feature, it should be advertising support for protocol 1 and not advertising support for protocols 0 or 0xFFF in its LSP. However, indication of support or non-support for RBridge Channel protocol 1 is ignored on receipt, and support for it is always assumed if support for any RBridge Channel is indicated in the RBridge's LSP.
RBridgeチャネルプロトコル0および0xFFFは予約されています。プロトコル1、RBridgeチャネルエラープロトコルは、RBridgeチャネル機能の一部として実装する必要があります。したがって、RBridgeがRBridge Channel機能をサポートしている場合は、プロトコル1のサポートをアドバタイズし、LSPのプロトコル0または0xFFFのサポートをアドバタイズしないでください。ただし、RBridgeチャネルプロトコル1のサポートまたは非サポートの指示は受信時に無視され、RBridgeのLSPでRBridgeチャネルのサポートが指示されている場合は常にサポートされていると見なされます。
The bandwidth resources used by RBridge Channel protocols are recommended to be small compared to the total bandwidth of the links they traverse. When doing network planning, the bandwidth requirements for TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge Channel protocol traffic, and any other link-local traffic need to be taken into account.
RBridgeチャネルプロトコルが使用する帯域幅リソースは、それらが通過するリンクの合計帯域幅と比較して小さいことが推奨されます。ネットワーク計画を行うときは、TRILLデータ、TRILL IS-IS、TRILL ESADI、RBridgeチャネルプロトコルトラフィック、およびその他のリンクローカルトラフィックの帯域幅要件を考慮する必要があります。
Specifications for particular RBridge Channel protocols MUST consider congestion and bandwidth usage implications and provide guidance on bandwidth or packet-frequency management. RBridge Channel protocols can have built-in bandwidth management in their protocols. Outgoing channel messages SHOULD be rate-limited, by configuring the underlying protocols or otherwise, to prevent aggressive connectivity verification or other applications consuming excessive bandwidth, causing congestion, or becoming denial-of-service attacks.
特定のRBridgeチャネルプロトコルの仕様は、輻輳と帯域幅使用の影響を考慮し、帯域幅またはパケット周波数管理に関するガイダンスを提供する必要があります。 RBridgeチャネルプロトコルは、プロトコルに帯域幅管理を組み込むことができます。発信チャネルメッセージは、積極的な接続検証や他のアプリケーションが過剰な帯域幅を消費し、輻輳を引き起こしたり、サービス拒否攻撃になるのを防ぐために、基になるプロトコルを設定するなどしてレート制限する必要があります。
If these conditions cannot be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing RBridge Channel traffic, so that it competes fairly, taking into account packet priorities and drop eligibility as indicated in the Inner.VLAN, with TCP or similar traffic within an order of magnitude. One method of determining an acceptable bandwidth for RBridge Channel traffic is described in [RFC5348]; other methods exist. For example, bandwidth or packet-frequency management can include any of the following: a negotiation of transmission interval/rate such as that provided in BFD [RFC5880], a throttled transmission rate on "congestion detected" situations, a gradual ramp-up after shutdown due to congestion and until basic connectivity is verified, and other mechanisms.
これらの条件が守られない場合は、適応型の損失ベースのスキームを輻輳制御の発信RBridgeチャネルトラフィックに適用して、パケットの優先順位を考慮して公平に競合し、TCPまたは1桁以内の同様のトラフィック。 RBridgeチャネルトラフィックの許容帯域幅を決定する1つの方法は、[RFC5348]で説明されています。他の方法が存在します。たとえば、帯域幅またはパケット周波数の管理には、次のいずれかを含めることができます。BFD[RFC5880]で提供されるような送信間隔/レートのネゴシエーション、「輻輳が検出された」状況での調整された送信レート、その後の漸進的なランプアップ輻輳による、基本的な接続が確認されるまでのシャットダウン、およびその他のメカニズム。
Connectivity-checking applications such as BFD [RFC5880] SHOULD be rate-limited to below 5% of the bitrate of the associated link or links. For this purpose, the mean or sustained bitrate of the link or links is used.
BFD [RFC5880]などの接続確認アプリケーションは、関連するリンクのビットレートの5％未満にレート制限する必要があります（SHOULD）。この目的のために、1つまたは複数のリンクの平均ビットレートまたは持続ビットレートが使用されます。
Incoming RBridge Channel messages MAY be rate-limited as a protection against denial-of-service attacks. This throttling of incoming messages SHOULD honor packet priorities and drop eligibility indications as indicated in the Inner.VLAN, preferentially discarding drop-eligible and lower-priority packets.
着信RBridgeチャネルメッセージは、サービス拒否攻撃に対する保護としてレート制限される場合があります。この着信メッセージのスロットリングは、Inner.VLANに示されているように、パケットの優先順位とドロップの適格性の指示を尊重し、ドロップ適格で優先度の低いパケットを優先的に破棄する必要があります（SHOULD）。
The following subsections give IANA and IEEE allocation considerations. In this document, the allocation procedure specifications are as defined in [RFC5226].
以下のサブセクションでは、IANAとIEEEの割り当てに関する考慮事項を示します。このドキュメントでは、割り当て手順の仕様は[RFC5226]で定義されています。
IANA has allocated a previously unassigned TRILL Nickname as follows:
IANAは、未割り当てのTRILLニックネームを次のように割り当てました。
Any-RBridge 0xFFC0
Any-RBridge 0xFFC0
IANA has added "All-Egress-RBridges" to the TRILL Parameter Registry as an alternative name for the "All-ESADI-RBridges" multicast address.
IANAは、「All-ESADI-RBridges」マルチキャストアドレスの代替名として「All-Egress-RBridges」をTRILLパラメータレジストリに追加しました。
IANA has allocated two previously unassigned TRILL multicast addresses as follows:
IANAは、以前は割り当てられていなかった2つのTRILLマルチキャストアドレスを次のように割り当てました。
TRILL-End-Stations 01-80-C2-00-00-45 All-Edge-RBridges 01-80-C2-00-00-46
TRILL-End-Stations 01-80-C2-00-00-45 All-Edge-RBridges 01-80-C2-00-00-46
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Protocols, with initial contents as follows:
IANAは、RBridgeチャネルプロトコルのTRILLパラメータレジストリに追加のサブレジストリを作成しました。初期コンテンツは次のとおりです。
Protocol Description Reference
-------- ----------- ---------
0x000 Reserved; not to be allocated (This document) 0x001 RBridge Channel Error (This document) 0x002-0x0FF Unassigned (1) 0x100-0xFF7 Unassigned (2) 0xFF8-0xFFE Reserved for Private Use 0xFFF Reserved; not to be allocated (This document)
0x000予約済み。割り当てられない（このドキュメント）0x001 RBridgeチャネルエラー（このドキュメント）0x002-0x0FF未割り当て（1）0x100-0xFF7未割り当て（2）0xFF8-0xFFE私用に予約0xFFF予約済み。割り当てられません（このドキュメント）
(1) RBridge Channel protocol code points from 0x002 to 0x0FF require a Standards Action, as modified by [RFC7120], for allocation.
（1）0x002から0x0FFまでのRBridgeチャネルプロトコルコードポイントには、[RFC7120]によって変更された標準アクションが割り当てに必要です。
(2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC Required to allocate a single value or IESG Approval to allocate multiple values.
（2）0x100から0xFF7のRBridgeチャネルプロトコルコードポイントは、単一の値を割り当てるためにRFCが必要か、複数の値を割り当てるためにIESG承認です。
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Header Flags with initial contents as follows:
IANAは、RBridgeチャネルヘッダーフラグのTRILLパラメータレジストリに追加のサブレジストリを作成しました。初期の内容は次のとおりです。
Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent 1 MH Multi-hop 2 NA Native 3-11 - Unassigned
0 SLサイレント1 MHマルチホップ2 NAネイティブ3-11-未割り当て
Allocation of an RBridge Channel Header Flag is based on IETF Review.
RBridgeチャネルヘッダーフラグの割り当ては、IETFレビューに基づいています。
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Error Codes with initial contents as listed in Section 3.2 above and with available values allocated by Standards Action as modified by [RFC7120].
IANAは、RBridgeチャネルエラーコード用のTRILLパラメータレジストリに追加のサブレジストリを作成しました。初期コンテンツは上記のセクション3.2に記載されており、[RFC7120]によって変更された標準アクションによって使用可能な値が割り当てられています。
The IEEE Registration Authority has assigned the Ethertype 0x8946 for TRILL RBridge Channel.
IEEE Registration Authorityは、TRILL RBridge ChannelにEthertype 0x8946を割り当てています。
No general integrity, authentication, or encryption mechanisms are provided herein for RBridge Channel messages. If these services are required for a particular RBridge Channel protocol, they MUST be supplied by that channel protocol. See, for example, the BFD Authentication mechanism [RFC5880].
本明細書では、RBridge Channelメッセージの一般的な整合性、認証、または暗号化メカニズムは提供されていません。これらのサービスが特定のRBridgeチャネルプロトコルに必要な場合、それらはそのチャネルプロトコルによって提供される必要があります。たとえば、BFD認証メカニズム[RFC5880]を参照してください。
See [RFC6325] for general TRILL security considerations. As stated therein, no protection is provided by TRILL against forging of the Ingress Nickname in a TRILL Data formatted channel message or the Outer.MacSA in a native RBridge Channel frame on an Ethernet link. This may result in misdirected return responses or error messages. However, link-level security protocols may be used to authenticate the origin station on a link and protect against attacks on links. See also Section 6 concerning congestion.
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。そこに述べられているように、TRILLは、TRILLデータ形式のチャネルメッセージのIngress Nickname、またはイーサネットリンクのネイティブRBridge ChannelフレームのOuter.MacSAの偽造に対する保護を提供していません。これにより、誤った方向の応答またはエラーメッセージが返される場合があります。ただし、リンクレベルのセキュリティプロトコルを使用して、リンク上の発信元ステーションを認証し、リンクへの攻撃から保護することができます。混雑については、セクション6も参照してください。
If indications of RBridge Channel Protocol support are improperly absent from an RBridge's LSP, it could deny all RBridge Channel services, for example, some BFD services, for the RBridge in question. If a particular RBridge Channel protocol is incorrectly not advertised as supported, it could deny the service of that channel protocol to the RBridge in question.
RBridge Channel Protocolサポートの表示がRBridgeのLSPに不適切に存在しない場合、問題のRBridgeに対するすべてのRBridge Channelサービス、たとえば一部のBFDサービスを拒否する可能性があります。特定のRBridge Channelプロトコルがサポート対象として誤ってアドバタイズされない場合、問題のRBridgeに対するそのチャネルプロトコルのサービスを拒否する可能性があります。
Incorrect indication of RBridge Channel Protocol support or incorrect assertion of support for a channel protocol could encourage RBridge Channel messages to be sent to an RBridge that does not support the channel feature or the particular channel protocol used. The inner frame of such messages could be decapsulated and that inner frame could be sent out all ports that are Appointed Forwarders for the frame's Inner.VLAN. However, this is unlikely to cause much harm; in particular, there are two possibilities as follows: (a) if end stations do not recognize the RBridge-Channel Ethertype of the frame, they will drop it, and (b) if end stations do recognize the RBridge-Channel Ethertype and the channel protocol indicated in the frame, they should refuse to process the frame due to an incorrect value of the RBridge Channel Header NA flag.
RBridge Channel Protocolサポートの誤った表示またはチャネルプロトコルのサポートの誤ったアサーションは、RBridge Channelメッセージが、使用されているチャネル機能または特定のチャネルプロトコルをサポートしないRBridgeに送信されることを促す可能性があります。このようなメッセージの内部フレームはカプセル化を解除でき、その内部フレームは、フレームのInner.VLANのAppointed Forwarderであるすべてのポートに送信できます。ただし、これが大きな害を及ぼすことはほとんどありません。特に、次の2つの可能性があります。（a）端末がフレームのRBridge-Channel Ethertypeを認識しない場合、フレームをドロップします。（b）端末がRBridge-Channel Ethertypeとチャネルを認識した場合フレームに示されたプロトコルでは、RBridge Channel Header NAフラグの値が正しくないため、フレームの処理を拒否する必要があります。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システム間ドメイン内ルーティング情報交換プロトコル」、第2版、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、2008年9月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.
[RFC7120]コットン、M。、「規格トラックコードポイントの初期IANA割り当て」、BCP 100、RFC 7120、2014年1月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、May 2014。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014.
[RFC7179] Eastlake 3rd、D.、Ghanwani、A.、Manral、V.、Li、Y.、and C. Bestler、 "Transparent Interconnection of Lots of Links（TRILL）：Header Extension"、RFC 7179、May 2014。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「Generalized TTL Security Mechanism（GTSM）」、RFC 5082、2007年10月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M。、編、Vigoureux、M、編、およびS. Bryant、編、「MPLS Generic Associated Channel」、RFC 5586、2009年6月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882] Katz、D。およびD. Ward、「Generic Application of Bidirectional Forwarding Detection（BFD）」、RFC 5882、2010年6月。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、2014年5月。
The authors gratefully acknowledge the comments and contributions of the follows, listed is alphabetic order: Stewart Bryant, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa Senevirathne.
著者は以下のコメントと貢献を感謝の気持ちで認め、アルファベット順でリストします。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
Donald Eastlake 3rd Huawei R＆D USA 155 Beaver Street Milford、MA 01757 USA電話：+ 1-508-333-2270メール：d3e3e3@gmail.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA EMail: vishwas@ionosnetworks.com
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 SunJosé、of 95117彼にメールを送る：faith@iononetwerks.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56622310 EMail: liyizhou@huawei.com
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国電話：+ 86-25-56622310メール：Li Yizhou@Huawei.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-5000 EMail: sam.aldrin@huawei.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050 USA電話：+ 1-408-330-5000メール：sam.aldrin@huawei.com
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: dward@cisco.com