RFC 7173 - Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7173
タイトル : RFC 7173 - 疑似配線を使用した多数のリンクの透過的な相互接続（TRILL）トランスポート
翻訳編集 : 自動生成

[要約] RFC 7173は、TRILL（Transparent Interconnection of Lots of Links）トランスポートを実現するための擬似ワイヤを使用する方法についての規格です。このRFCの目的は、TRILLネットワークの拡張性と柔軟性を向上させるために、擬似ワイヤを使用したトランスポートの仕組みを提案することです。

Internet Engineering Task Force (IETF)                           L. Yong
Request for Comments: 7173                               D. Eastlake 3rd
Category: Standards Track                                      S. Aldrin
ISSN: 2070-1721                                                   Huawei
                                                               J. Hudson
                                                                 Brocade
                                                                May 2014

Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires

疑似配線を使用した多数のリンクの透過的な相互接続（TRILL）トランスポート

Abstract

概要

This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.

このドキュメントでは、既存のTRILLおよび疑似配線エミュレーションエンドツーエンド（PWE3）標準の疑似配線を使用して、リンクの透過的な相互接続（TRILL）スイッチポートのペアを相互接続する方法について説明します。

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/rfc7173.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7173で入手できます。

著作権表示

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.....................................................2
      1.1. Conventions Used in This Document...........................2
   2. PWE3 Interconnection of TRILL Switches...........................3
      2.1. PWE3 Type-Independent Details...............................3
      2.2. PPP PWE3 Transport of TRILL.................................4
   3. Security Considerations..........................................6
   Appendix A. Use of Other Pseudowire Types ..........................7
   Acknowledgements ...................................................8
   Normative References ...............................................9
   Informative References ............................................10

1. Introduction

1. はじめに

The Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise data frame routing without configuration in multi-hop networks with arbitrary topology. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement TRILL are called TRILL switches or Routing Bridges (RBridges).

リンクの透過的相互接続（TRILL）プロトコル[RFC6325]は、任意のトポロジーを持つマルチホップネットワークでの構成なしに、最適なペアワイズデータフレームルーティングを提供します。 TRILLは、ユニキャストとマルチキャストの両方のトラフィックのマルチパスをサポートしています。 TRILLを実装するデバイスは、TRILLスイッチまたはルーティングブリッジ（RBridge）と呼ばれます。

Links between TRILL switches can be based on arbitrary link protocols, for example, PPP [RFC6361], as well as Ethernet [RFC6325]. A set of connected TRILL switches together form a TRILL campus that is bounded by end stations and Layer 3 routers.

TRILLスイッチ間のリンクは、イーサネット[RFC6325]だけでなく、PPP [RFC6361]などの任意のリンクプロトコルに基づくことができます。接続されたTRILLスイッチのセットは、端末ステーションとレイヤー3ルーターによって境界が定められたTRILLキャンパスを形成します。

This document specifies how to interconnect a pair of TRILL switch ports using a pseudowire under existing TRILL and PWE3 (Pseudowire Emulation End-to-End) standards.

このドキュメントでは、既存のTRILLおよびPWE3（Pseudowire Emulation End-to-End）規格に基づいて、疑似配線を使用してTRILLスイッチポートのペアを相互接続する方法について説明します。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

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]で説明されているように解釈されます。

Acronyms used in this document include the following:

このドキュメントで使用されている頭字語は次のとおりです。

IS-IS - Intermediate System to Intermediate System [IS-IS]

IS-IS-中間システムから中間システム[IS-IS]

MPLS - Multi-Protocol Label Switching

MPLS-マルチプロトコルラベルスイッチング

PPP - Point-to-Point Protocol [RFC1661]

PPP-ポイントツーポイントプロトコル[RFC1661]

PW - Pseudowire [RFC3985] PWE3 - PW Emulation End-to-End

PW-疑似配線[RFC3985] PWE3-PWエミュレーションエンドツーエンド

RBridge - Routing Bridge, an alternative name for a TRILL switch

RBridge-TRILLスイッチの別名、ルーティングブリッジ

TRILL - Transparent Interconnection of Lots of Links [RFC6325]

TRILL-多くのリンクの透過的な相互接続[RFC6325]

TRILL Switch - A device implementing the TRILL protocol

TRILLスイッチ-TRILLプロトコルを実装するデバイス

2. PWE3 Interconnection of TRILL Switches

2. TRILLスイッチのPWE3相互接続

When a pseudowire is used to interconnect a pair of TRILL switch ports, a PPP [RFC4618] pseudowire is used as described below. The pseudowire between such ports can be signaled [RFC4447] or manually configured. In this context, the TRILL switch ports at the ends of the pseudowire are acting as native service processing (NSP) elements [RFC3985] and, assuming that the pseudowires are over MPLS or IP [RFC4023] networks, as label switched or IP routers at the TRILL switch ports.

疑似配線を使用して1組のTRILLスイッチポートを相互接続する場合、PPP [RFC4618]疑似配線が以下のように使用されます。このようなポート間の疑似配線は、[RFC4447]で通知するか、手動で設定できます。このコンテキストでは、疑似配線の端にあるTRILLスイッチポートはネイティブサービス処理（NSP）要素として機能し[RFC3985]、疑似配線がMPLSまたはIP [RFC4023]ネットワーク上にあると仮定して、ラベルスイッチまたはIPルーターとしてTRILLスイッチポート。

Pseudowires provide transparent transport, and the two TRILL switch ports appear directly interconnected with a transparent link. With such an interconnection, the TRILL adjacency over the link is automatically discovered and established through TRILL IS-IS control messages [RFC7177].

疑似配線は透過的なトランスポートを提供し、2つのTRILLスイッチポートは、透過的なリンクで直接相互接続されているように見えます。このような相互接続により、リンク上のTRILL隣接関係は自動的に検出され、TRILL IS-IS制御メッセージ[RFC7177]を通じて確立されます。

A pseudowire is carried over a packet switched network tunnel [RFC3985], for example, an MPLS or MPLS-TP label switched path tunnel in MPLS networks. Either a signaling protocol or manual configuration can be used to configure a label switched path tunnel between two TRILL switch ports. This application needs no additions to the existing pseudowire standards.

疑似配線は、パケット交換ネットワークトンネル[RFC3985]、たとえばMPLSネットワークのMPLSまたはMPLS-TPラベルスイッチドパストンネルを介して伝送されます。シグナリングプロトコルまたは手動設定のいずれかを使用して、2つのTRILLスイッチポート間のラベルスイッチドパストンネルを設定できます。このアプリケーションは、既存の疑似配線標準に追加する必要はありません。

2.1. PWE3 Type-Independent Details

2.1. PWE3タイプに依存しない詳細

The sending pseudowire TRILL switch port SHOULD map the inner priority of the TRILL Data packets being sent to the Traffic Class field of the pseudowire label [RFC5462] so as to minimize the probability that higher priority TRILL Data packets will be discarded due to excessive TRILL Data packets of lower priority.

送信する疑似配線TRILLスイッチポートは、送信されるTRILLデータパケットの内部優先度を疑似配線ラベル[RFC5462]のトラフィッククラスフィールドにマッピングして、過剰なTRILLデータが原因で優先度の高いTRILLデータパケットが破棄される確率を最小限に抑える必要があります。優先度の低いパケット。

TRILL IS-IS PDUs critical to establishing and maintaining adjacency (Hello and MTU PDUs) SHOULD be sent with the MPLS Traffic Class that calls for handling with the maximum priority. Other TRILL IS-IS PDUs SHOULD be sent with the MPLS Traffic Class denoting the highest priority that is less than the maximum priority. TRILL Data packets SHOULD be sent with appropriate MPLS Traffic Classes, typically mapped from the TRILL Data packet priority, such that TRILL Data packet Traffic Classes denote priorities less than the priorities used for TRILL IS-IS PDUs. This minimizes the probability of other traffic interfering with these important control PDUs and causing false loss of adjacency or other control problems.

隣接関係の確立と維持に重要なTRILL IS-IS PDU（Hello PDUとMTU PDU）は、最大の優先度で処理を要求するMPLSトラフィッククラスで送信する必要があります（SHOULD）。他のTRILL IS-IS PDUは、最高の優先度よりも低い最高の優先度を示すMPLSトラフィッククラスで送信する必要があります（SHOULD）。 TRILLデータパケットは、通常TRILLデータパケットの優先度からマッピングされた適切なMPLSトラフィッククラスを使用して送信する必要があります。これにより、TRILLデータパケットトラフィッククラスは、TRILL IS-IS PDUに使用される優先度よりも低い優先度を示します。これにより、他のトラフィックがこれらの重要な制御PDUに干渉して、隣接関係の誤った喪失や他の制御問題を引き起こす可能性を最小限に抑えます。

If a pseudowire supports fragmentation and reassembly (a feature that has received little or no deployment), then there is no reason to do TRILL MTU testing on it, and the pseudowire will not be a constraint on the TRILL campus-wide MTU size (Sz) (see Section 4.3.1 of [RFC6325]). If the pseudowire does not support fragmentation (the more common case), then the available TRILL IS-IS packet payload size over the pseudowire (taking into account MPLS encapsulation with a control word) or some lower value, MUST be used in helping to determine MTU size (Sz) (see Section 5 of [RFC7180]).

疑似配線が断片化と再構成をサポートしている場合（ほとんどまたはまったく展開されていない機能）、その疑似配線でTRILL MTUテストを実行する理由はなく、疑似配線はTRILLキャンパス全体のMTUサイズ（Sz ）（[RFC6325]のセクション4.3.1を参照）。疑似配線がフラグメンテーションをサポートしない場合（より一般的なケース）、疑似配線上で利用可能なTRILL IS-ISパケットのペイロードサイズ（制御ワードを使用したMPLSカプセル化を考慮に入れる）、またはそれより低い値を使用して、決定を支援する必要があります。 MTUサイズ（Sz）（[RFC7180]のセクション5を参照）。

An intervening MPLS label switched router or similar packet switched network device has no awareness of TRILL. Such devices will not change the TRILL Header hop count.

介在するMPLSラベルスイッチドルータまたは同様のパケットスイッチドネットワークデバイスは、TRILLを認識しません。このようなデバイスは、TRILLヘッダーのホップカウントを変更しません。

2.2. PPP PWE3 Transport of TRILL

2.2. PPP PWE3 TRILLの移送

For a PPP pseudowire (PW type = 0x0007), the two TRILL switch ports being connected are configured to form a pseudowire with PPP encapsulation [RFC4618]. After the pseudowire is established and TRILL use is negotiated within PPP, the two TRILL switch ports appear directly connected with a PPP link [RFC1661] [RFC6361].

PPP疑似配線（PWタイプ= 0x0007）の場合、接続されている2つのTRILLスイッチポートは、PPPカプセル化を使用して疑似配線を形成するように構成されます[RFC4618]。疑似配線が確立され、PPP内でTRILLの使用がネゴシエートされると、2つのTRILLスイッチポートがPPPリンク[RFC1661] [RFC6361]に直接接続されているように見えます。

If pseudowire interconnection of two TRILL switch ports is signaled [RFC4447], the initiating TRILL switch port MUST attempt the connection setup with pseudowire type PPP (0x0007).

2つのTRILLスイッチポートの疑似配線相互接続が通知された場合[RFC4447]、開始TRILLスイッチポートは疑似配線タイプPPP（0x0007）で接続セットアップを試行する必要があります。

Behavior for TRILL with a PPP pseudowire continues to follow that of TRILL over PPP as specified in Section 3 of [RFC6361].

[RFC6361]のセクション3で指定されているように、PPP疑似配線を使用したTRILLの動作は、引き続きPPPを介したTRILLの動作に従います。

The following figures show what a TRILL Data packet and TRILL IS-IS packet look like over such a pseudowire in the MPLS case, assuming no TRILL Header extensions:

次の図は、TRLSヘッダー拡張がないと仮定して、MPLSの場合のこのような疑似配線上でのTRILLデータパケットとTRILL IS-ISパケットの外観を示しています。

   +--------------------------------+
   |   Server MPLS Tunnel Label(s)  |  n*4 octets (4 octets per label)
   +--------------------------------+
   |           PW Label             |  4 octets
   +--------------------------------+
   |         Control Word           |  4 octets
   +--------------------------------+
   |      PPP Header 0x005d         |  2 octets
   +--------------------------------+
   |         TRILL Header           |  6 octets
   +--------------------------------+
   |    Destination MAC Address     |  6 octets
   +--------------------------------+
   |      Source MAC Address        |  6 octets
   +--------------------------------+
   |          Data Label            |  4 or 8 octets
   +--------------------------------+
   |         Payload Body           |  variable
   +--------------------------------+

Figure 1: TRILL Data Packet in Pseudowire

図1：疑似配線のTRILLデータパケット

"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload.

「データラベル」は、ペイロードのVLANラベルまたは細粒度ラベル[RFC7172]です。

   +--------------------------------+
   |   Server MPLS Tunnel Label(s)  |  n*4 octets (4 octets per label)
   +--------------------------------+
   |           PW Label             |  4 octets
   +--------------------------------+
   |         Control Word           |  4 octets
   +--------------------------------+
   |      PPP Header 0x405d         |  2 octets
   +--------------------------------+
   |     Common IS-IS Header        |  8 octets
   +--------------------------------+
   | IS-IS PDU Type Specific Header |  variable
   +--------------------------------+
   |          IS-IS TLVs            |  variable
   +--------------------------------+

Figure 2: TRILL IS-IS Packet in Pseudowire

図2：PseudowireのTRILL IS-ISパケット

The PPP Header fields (0x005d and 0x405d, respectively) for TRILL Data and IS-IS packets shown above are specified in [RFC6361].

上記のTRILLデータとIS-ISパケットのPPPヘッダーフィールド（それぞれ0x005dと0x405d）は、[RFC6361]で指定されています。

3. Security Considerations

3. セキュリティに関する考慮事項

TRILL-level security mechanisms, such as the ability to use authentication with TRILL IS-IS PDUs [RFC6325], are not affected by link technology, such as the use of pseudowire links as specified in this document.

TRILL IS-IS PDU [RFC6325]で認証を使用する機能などのTRILLレベルのセキュリティメカニズムは、このドキュメントで指定されている疑似配線リンクの使用などのリンクテクノロジーの影響を受けません。

Link security may be useful in improving TRILL campus security. TRILL is transported over pseudowires as TRILL over PPP over pseudowires, pseudowires are over MPLS or IP, and MPLS and IP are over some lower-level link technology. Thus, link security below the TRILL level for a pseudowire link could be provided by PPP security, pseudowire security, MPLS or IP security, or security of the link technology supporting MPLS or IP.

リンクのセキュリティは、TRILLキャンパスのセキュリティを向上させるのに役立ちます。 TRILLは、疑似配線を介したPPPを介したTRILL、疑似配線はMPLSまたはIPを介して、およびMPLSとIPはいくつかの低レベルリンクテクノロジーを介して、疑似配線を介して転送されます。したがって、疑似配線リンクのTRILLレベルより下のリンクセキュリティは、PPPセキュリティ、疑似配線セキュリティ、MPLSまたはIPセキュリティ、またはMPLSまたはIPをサポートするリンクテクノロジーのセキュリティによって提供できます。

PPP TRILL security considerations are discussed in [RFC6361]. For security considerations introduced by carrying PPP TRILL links over pseudowires, see [RFC3985], which discusses the risks introduced by sending protocols that previously assumed a point-to-point link on a pseudowire built on a packet switched network (PSN). However, the PPP layer in TRILL transport by pseudowire is somewhat vestigial and intended primarily as a convenient way to use existing PPP code points to identify TRILL Data packets and TRILL IS-IS packets. Furthermore, existing PPP security standards are arguably questionable in terms of current security criteria. For these reasons, it is NOT RECOMMENDED to use PPP security in the transport of TRILL by pseudowires as specified in this document.

PPP TRILLのセキュリティに関する考慮事項は、[RFC6361]で説明されています。疑似配線を介してPPP TRILLリンクを伝送することによって導入されるセキュリティの考慮事項については、[RFC3985]を参照してください。これは、パケット交換ネットワーク（PSN）上に構築された疑似配線でポイントツーポイントリンクを以前想定していたプロトコルを送信することによって導入されるリスクについて説明しています。ただし、疑似配線によるTRILLトランスポートのPPP層はやや痕跡があり、主に既存のPPPコードポイントを使用してTRILLデータパケットとTRILL IS-ISパケットを識別する便利な方法として意図されています。さらに、既存のPPPセキュリティ標準は、現在のセキュリティ基準の点で間違いなく疑わしいものです。これらの理由から、このドキュメントで指定されている疑似配線によるTRILLの転送でPPPセキュリティを使用することはお勧めしません。

It is RECOMMENDED that link security be provided at the layers supporting pseudowires transporting TRILL, that is, at the MPLS or IP layer or the link layer transporting MPLS or IP.

リンクセキュリティは、TRILLを転送する疑似配線をサポートするレイヤー、つまりMPLSまたはIPレイヤー、またはMPLSまたはIPを転送するリンクレイヤーで提供することをお勧めします。

For applications involving sensitive data, end-to-end security should always be considered, in addition to link security, to provide security in depth. In this context, such end-to-end security should be between the end stations involved so as to protect the entire path to, through, and from the TRILL campus.

機密データを含むアプリケーションの場合は、リンクセキュリティに加えて、エンドツーエンドのセキュリティを常に考慮して、セキュリティを詳細に提供する必要があります。このコンテキストでは、そのようなエンドツーエンドのセキュリティは、関係するエンドステーション間にある必要があります。これにより、TRILLキャンパスへの、そこからの、およびそこからのパス全体が保護されます。

For general TRILL protocol security considerations, see [RFC6325].

TRILLプロトコルのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。

Appendix A. Use of Other Pseudowire Types

付録A.他の疑似配線タイプの使用

This informational appendix briefly discusses the use of pseudowire types other than PPP for the transport of TRILL.

この付録では、TRILLの転送にPPP以外の疑似配線タイプを使用する方法について簡単に説明します。

The use of Ethernet pseudowires [RFC4448] was examined by the authors and would be possible without change to such pseudowires; however, this would require an additional 12 or 16 bytes per packet within the payload being transmitted over the pseudowire for a TRILL Data packet (Figure 3) and a TRILL IS-IS packet (Figure 4) over such an Ethernet pseudowire in the MPLS case, assuming no TRILL Header extensions (compare with Figures 1 and 2):

イーサネット疑似配線[RFC4448]の使用は著者によって検討されており、そのような疑似配線を変更しなくても可能です。ただし、これには、MPLSの場合、TRILLデータパケット（図3）およびそのようなイーサネット疑似配線を介したTRILL IS-ISパケット（図4）の疑似配線を介して送信されるペイロード内のパケットごとに追加の12または16バイトが必要になります。、TRILLヘッダー拡張がないと仮定（図1および2と比較）：

   +--------------------------------+
   |   Server MPLS Tunnel Label(s)  |  n*4 octets (4 octets per label)
   +--------------------------------+
   |          PW Label              |  4 octets
   +--------------------------------+
   |    Optional Control Word       |  4 octets
   +--------------------------------+
   |  TRILL Hop Dest. MAC Address   |  6 octets
   +--------------------------------+
   |  TRILL Hop Source MAC Address  |  6 octets
   +--------------------------------+
   |Optional VLAN and/or other tags |  variable
   +--------------------------------+
   |   TRILL Ethertype (0x22f3)     |  2 octets
   +--------------------------------+
   |         TRILL Header           |  6 octets
   +--------------------------------+
   |    Destination MAC Address     |  6 octets
   +--------------------------------+
   |      Source MAC Address        |  6 octets
   +--------------------------------+
   |          Data Label            |  4 or 8 octets
   +--------------------------------+
   |         Payload Body           |  variable
   +--------------------------------+

Figure 3: TRILL Data Packet in Ethernet Pseudowire

図3：イーサネット疑似配線のTRILLデータパケット

"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload.

「データラベル」は、ペイロードのVLANラベルまたは細粒度ラベル[RFC7172]です。

   +--------------------------------+
   |   Server MPLS Tunnel Label(s)  |  n*4 octets (4 octets per label)
   +--------------------------------+
   |          PW Label              |  4 octets
   +--------------------------------+
   |    Optional Control Word       |  4 octets
   +--------------------------------+
   |  TRILL Hop Dest. MAC Address   |  6 octets
   +--------------------------------+
   |  TRILL Hop Source MAC Address  |  6 octets
   +--------------------------------+
   |Optional VLAN and/or other tags |  variable
   +--------------------------------+
   | Layer 2 IS-IS Ethertype 0x22f4 |  2 octets
   +--------------------------------+
   |       Common IS-IS Header      |  8 octets
   +--------------------------------+
   | IS-IS PDU Type Specific Header |  variable
   +--------------------------------+
   |          IS-IS TLVs            |  variable
   +--------------------------------+

Figure 4: TRILL IS-IS Packet in Ethernet Pseudowire

図4：イーサネット疑似配線のTRILL IS-ISパケット

It would also be possible to specify a new pseudowire type for TRILL traffic, but the authors feel that any efficiency gain over PPP pseudowires would be too small to be worth the complexity of adding such a specification. Furthermore, using PPP pseudowire encoding means that any traffic dissector that understands TRILL PPP encoding [RFC6361] and PPP pseudowires [RFC4618] will automatically be able to recursively decode TRILL transported by pseudowire.

TRILLトラフィックに新しい疑似配線タイプを指定することも可能ですが、PPP疑似配線を介した効率の向上は小さすぎて、そのような仕様を追加する複雑さに見合わないと感じています。さらに、PPP疑似配線エンコーディングを使用すると、TRILL PPPエンコーディング[RFC6361]およびPPP疑似配線[RFC4618]を理解するトラフィックディセクタは、疑似配線によって転送されたTRILLを自動的に再帰的にデコードできます。

Acknowledgements

謝辞

Thanks for the valuable comments from the following, who are listed in alphabetic order:

アルファベット順に記載されている以下の貴重なコメントをありがとう：

Stewart Bryant, Stephen Farrell, Brian Haberman, Christer Holmberg, Joel Jaeggli, Barry Leiba, Erik Nordmark, Yaron Sheffer, and Yaakov (J) Stein.

スチュワートブライアント、スティーブンファレル、ブライアンハーバーマン、クリスターホルムバーグ、ジョエルジャグリ、バリーレイバ、エリックノードマーク、ヤロンシェファー、ヤアコフ（J）シュタイン。

Normative References

引用文献

[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[RFC1661] Simpson、W.、Ed。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。

[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月。

[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.

[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。

[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.

[RFC4618] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP /高レベルデータリンク制御（HDLC）のトランスポートのカプセル化方法」、RFC 4618、2006年9月。

[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.

[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、2009年2月。

[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月。

[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.

[RFC6361] Carlson、J。およびD. Eastlake 3度、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、2011年8月。

[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.

[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、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, 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月。

Informative References

参考引用

[IS-IS] ISO/IEC 10589:2002, Second Edition, "Information technology -- Telecommunications and information exchange between systems -- 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)", 2002.

[IS-IS] ISO / IEC 10589：2002、Second Edition、 "Information technology-Telecommunications and information exchange between systems-Intermediate System to Intermediate System intra-domain routinging information exchange protocol with used with with the protocol with with with using the protocol toコネクションレスモードのネットワークサービス（ISO 8473）」、2002年。

[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC3985] Bryant、S.、Ed。およびP. Pate、Ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。

[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、2005年3月。

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.

[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006。

[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。

Authors' Addresses

著者のアドレス

Lucy Yong Huawei Technologies 5340 Legacy Drive Plano, TX 75024 USA

Lucy Yong hu Aはテクノロジー5340レガシードライブPLA no、TX 75024 USA

   Phone: +1-469-227-5837
   EMail: lucy.yong@huawei.com

Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA

Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA

   Phone: +1-508-333-2270
   EMail: d3e3e3@gmail.com

Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA

Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050 USA

   Phone: +1-408-330-4517
   EMail: sam.aldrin@huawei.com

Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 USA

Jon Hudson Brocade 130 Holger Way San Jose、CA 95134 USA

   Phone: +1-408-333-4062
   EMail: jon.hudson@gmail.com