[要約] RFC 7179は、TRILLヘッダー拡張に関する規格であり、TRILLネットワークでのヘッダー拡張の仕組みを提供する。目的は、TRILLヘッダーの柔軟性と拡張性を向上させ、ネットワークの効率性と機能性を向上させることである。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7179 Huawei
Updates: 6325 A. Ghanwani
Category: Standards Track Dell
ISSN: 2070-1721 V. Manral
Ionos Corp.
Y. Li
Huawei
C. Bestler
Nexenta Systems
May 2014
Transparent Interconnection of Lots of Links (TRILL): Header Extension
多くのリンクの透過的な相互接続（TRILL）：ヘッダー拡張
Abstract
概要
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.
IETFの多くのリンクの透過的相互接続（TRILL）基本プロトコル（RFC 6325）は、TRILLヘッダー拡張を安全にサポートするための最小限のフックを指定します。このドキュメントは、追加のフラグビットを提供する初期拡張を指定し、それらのビットのいくつかを指定します。 RFC 6325を更新します。
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/rfc7179.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7179で入手できます。
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. Conventions Used in This Document ..........................3
2. TRILL Header Extensions .........................................3
2.1. RBridge Extended Flag Handling Requirements ................5
2.2. No Critical Surprises ......................................5
2.3. Extended Header Flags ......................................6
2.3.1. Critical Summary Bits ...............................7
2.4. Conflict of Extensions .....................................8
3. Specific Extended Header Flags ..................................9
3.1. RBridge Channel Alert Extended Flags .......................9
4. Additions to IS-IS ..............................................9
5. IANA Considerations ............................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
The base IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides a TRILL Header extension feature and describes minimal hooks to safely support header extensions. (This feature is called "options" in Section 3.8 of [RFC6325].) But, except for the first two bits, the TRILL base protocol document does not specify the structure of extensions to the TRILL Header nor the details of any particular extension.
多くのリンクの基本IETF透過相互接続（TRILL）プロトコル[RFC6325]は、TRILLヘッダー拡張機能を提供し、ヘッダー拡張を安全にサポートするための最小限のフックを記述します。 （この機能は、[RFC6325]のセクション3.8では「オプション」と呼ばれています。）ただし、最初の2ビットを除いて、TRILLベースプロトコルドキュメントでは、TRILLヘッダーの拡張構造や特定の拡張の詳細は指定されていません。
This document is consistent with [RFC6325] and provides further details. It specifies an initial extension word providing additional flag bits and specifies some of those bits. Additional extensions, including TLV-encoded options, may be specified in later documents, for example, [Options] and [Options2].
このドキュメントは[RFC6325]と一貫性があり、詳細を提供します。これは、追加のフラグビットを提供する最初の拡張ワードを指定し、それらのビットのいくつかを指定します。 TLVエンコードオプションを含む追加の拡張機能は、[Options]や[Options2]など、後のドキュメントで指定される場合があります。
Section 2 below describes some general principles of TRILL Header extensions and an initial extension. Section 3 specifies a pair of flags in this initial extension.
以下のセクション2では、TRILLヘッダー拡張と初期拡張のいくつかの一般原則について説明します。セクション3では、この最初の拡張でフラグのペアを指定しています。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. Devices implementing the TRILL protocol are referred to as RBridges (Routing Bridges) or TRILL Switches.
[RFC6325]で定義されている用語と頭字語は、ここでは同じ意味で使用されます。 TRILLプロトコルを実装するデバイスは、RBridges（ルーティングブリッジ）またはTRILLスイッチと呼ばれます。
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 base TRILL protocol includes a feature for extension of the TRILL Header (see [RFC6325], Sections 3.5 and 3.8). The 5-bit Op-Length header field gives the length of the extensions to the TRILL Header in units of 4 octets, which allows up to 124 octets of header extension. If Op-Length is zero, there are no header extensions present; else, the extension area follows immediately after the Ingress RBridge Nickname field of the TRILL Header. The first 32-bit word of the optional extensions area consists of an extended flags area and critical summary bits as specified in this document.
基本TRILLプロトコルには、TRILLヘッダーの拡張機能が含まれています（[RFC6325]、セクション3.5および3.8を参照）。 5ビットのOp-Lengthヘッダーフィールドは、TRILLヘッダーの拡張の長さを4オクテット単位で示します。これにより、最大124オクテットのヘッダー拡張が可能になります。 Op-Lengthがゼロの場合、ヘッダー拡張はありません。それ以外の場合、拡張領域はTRILLヘッダーのIngress RBridge Nicknameフィールドの直後に続きます。オプションの拡張領域の最初の32ビットワードは、このドキュメントで指定されている拡張フラグ領域とクリティカルサマリービットで構成されています。
As described below, provision is made for
以下で説明するように、
o hop-by-hop flags, which might affect any RBridge that receives a TRILL Data frame with such a flag set,
o ホップバイホップフラグ。このようなフラグが設定されたTRILLデータフレームを受信するRBridgeに影響を与える可能性があります。
o ingress-to-egress flags, which would only necessarily affect the RBridge(s) where a TRILL frame is decapsulated,
o ingress-to-egressフラグ。これは、TRILLフレームがカプセル化解除されるRBridgeにのみ影響を与えるだけです。
o flags affecting an as-yet-unspecified class of RBridges, for example, border RBridges in a TRILL campus extended to support multi-level IS-IS (Intermediate System to Intermediate System) [MultiLevel], and
o 未指定のRBridgeクラスに影響を与えるフラグ。たとえば、マルチレベルIS-IS（中間システムから中間システム）[MultiLevel]をサポートするように拡張されたTRILLキャンパスの境界RBridge
o both "critical" and "non-critical" flags.
o 「クリティカル」および「非クリティカル」フラグの両方。
Any RBridge receiving a frame with a critical hop-by-hop extension that it does not implement MUST discard the frame because it is unsafe to process the frame without understanding such a critical extension.
クリティカルなホップバイホップ拡張が実装されていないフレームを受信するRBridgeは、そのような重要な拡張を理解せずにフレームを処理するのは安全でないため、フレームを破棄する必要があります。
Any egress RBridge receiving a frame with a critical ingress-to-egress extension it does not implement MUST drop the frame if it is a unicast frame (TRILL Header M bit = 0); if it is a multi-destination TRILL Data frame (M=1), then it MUST NOT be egressed at that RBridge, but the egress RBridge still forwards such a frame on the distribution tree.
ユニキャストフレーム（TRILLヘッダーMビット= 0）の場合、実装されていない重要な入出力拡張を備えたフレームを受信するすべての出力RBridgeは、そのフレームをドロップする必要があります。それが複数の宛先TRILLデータフレーム（M = 1）の場合、そのRBridgeで出力してはなりません（MUST）が、出力RBridgeはそのようなフレームを配信ツリーに転送します。
Non-critical extensions can be safely ignored.
重要でない拡張機能は無視しても問題ありません。
Any extended flag indicating a significant change in the structure or interpretation of later parts of the frame that, if the extended flag were ignored, could cause a failure of service or violation of security policy MUST be a critical extension. If such an extended flag affects any fields that transit RBridges will examine, it MUST be a hop-by-hop critical extended flag.
フレームの後半部分の構造または解釈の大幅な変更を示す拡張フラグは、拡張フラグが無視された場合、サービスの障害またはセキュリティポリシー違反の原因となる可能性があり、重要な拡張である必要があります。そのような拡張フラグがトランジットRBridgesが検査するフィールドに影響を与える場合、それはホップバイホップのクリティカル拡張フラグでなければなりません。
Note: Most RBridge implementations are expected to be optimized for simple and common cases of frame forwarding and processing. Although the hard limit on the header extensions area length, the 32-bit alignment of the extension area, and the presence of critical extension summary bits, as described below, are intended to assist in the efficient hardware processing of frames with a TRILL Header extensions area, nevertheless the inclusion of extensions may cause frame processing using a "slow path" with inferior performance to "fast path" processing. Limited slow path throughput of such frames could cause some of them to be discarded.
注：ほとんどのRBridge実装は、フレームの転送と処理の単純で一般的なケースに対して最適化されることが期待されています。ヘッダー拡張領域の長さのハード制限、拡張領域の32ビットアライメント、および重要な拡張サマリービットの存在は、以下で説明するように、TRILLヘッダー拡張を備えたフレームの効率的なハードウェア処理を支援することを目的としていますそれでも、拡張機能を含めると、「高速パス」処理よりもパフォーマンスが劣る「低速パス」を使用したフレーム処理が発生する可能性があります。このようなフレームの低速パスのスループットが制限されると、一部のフレームが破棄される可能性があります。
All RBridges MUST check whether there are any critical flags set that are necessarily applicable to their processing of the frame. To assist in this task, critical summary bits are provided that cover not only the extended flags specified herein but will cover any further extensions that may be specified in future documents, for example, [Options] and [Options2]. If an RBridge does not implement all critical flags in a TRILL Data frame, it MUST treat the frame as having an unimplemented critical extension as described in Section 2. A transit or egress RBridge may assume that the critical summary bits are correct.
すべてのRBridgeは、フレームの処理に必ず適用できるクリティカルフラグセットがあるかどうかを確認する必要があります。このタスクを支援するために、ここで指定された拡張フラグをカバーするだけでなく、[Options]や[Options2]などの将来のドキュメントで指定される可能性があるその他の拡張をカバーする重要なサマリービットが提供されます。 RBridgeがTRILLデータフレームにすべてのクリティカルフラグを実装しない場合、セクション2で説明されているように、フレームを実装されていないクリティカル拡張を持つものとして扱う必要があります。トランジットまたは出力RBridgeは、クリティカルサマリービットが正しいと想定する場合があります。
In addition, a transit RBridge:
さらに、トランジットRBridge：
o MAY set or clear hop-by-hop flags as specified for such flags;
o そのようなフラグに指定されているように、ホップバイホップのフラグを設定またはクリアできます。
o MUST adjust the length of the extensions area, including changing Op-Length in the TRILL Header, as appropriate if it adds or removes the extended header flags word;
o 拡張ヘッダーフラグワードを追加または削除する場合は、TRILLヘッダーのOp-Lengthの変更を含め、拡張領域の長さを適切に調整する必要があります。
o MUST, if it adds the word of extended header flags or changes any critical flags, correctly set the critical summary bits in the extended header flags word;
o 拡張ヘッダーフラグの単語を追加するか、重要なフラグを変更する場合は、拡張ヘッダーフラグの単語に重要な要約ビットを正しく設定する必要があります。
o MUST NOT remove the extended header flags word unless it is all zero (either on arrival or after permitted modifications); and
o 拡張ヘッダーフラグワードがすべてゼロでない限り（到着時または許可された変更後）、削除しないでください。そして
o MUST NOT set or clear ingress-to-egress or reserved extended header flags except as specifically permitted in the specification of such flags.
o そのようなフラグの仕様で特に許可されている場合を除き、入力から出力または予約された拡張ヘッダーフラグを設定またはクリアしてはなりません（MUST NOT）。
RBridges advertise the extended header flags they support in IS-IS PDUs (Protocol Data Units) [RFC7176]. Unless an RBridge advertises support for a critical extended header flag, it will not normally receive frames with that flag set. An RBridge is not required to support any extensions.
RBridgeは、IS-IS PDU（プロトコルデータユニット）[RFC7176]でサポートする拡張ヘッダーフラグを通知します。 RBridgeが重要な拡張ヘッダーフラグのサポートをアドバタイズしない限り、通常はそのフラグが設定されたフレームを受信しません。拡張機能をサポートするためにRBridgeは必要ありません。
An RBridge SHOULD NOT set a critical extended flag in a frame unless,
RBridgeは、以下の場合を除き、フレームにクリティカル拡張フラグを設定してはいけません（SHOULD NOT）。
o for a critical hop-by-hop extended header flag, it has determined that the next hop RBridge or RBridges that will accept the frame support that flag,
o クリティカルなホップバイホップ拡張ヘッダーフラグの場合、フレームを受け入れるネクストホップRBridgeがそのフラグをサポートすることが決定されています。
o for a critical ingress-to-egress extended header flag, it has determined that the RBridge or RBridges that will egress the frame support that flag, or
o 重要な入力から出力への拡張ヘッダーフラグの場合、フレームを出力する1つまたは複数のRBridgeがそのフラグをサポートしている、または
o for a critical reserved extended header flag, it may set such a flag only if it understands which RBridges it is applicable to and has determined that those RBridges that will accept the frame support that flag.
o クリティカルな予約済み拡張ヘッダーフラグの場合、該当するRBridgeが理解でき、フレームを受け入れるRBridgeがそのフラグをサポートしていると判断した場合にのみ、そのようなフラグを設定できます。
"SHOULD NOT" is specified above since there may be cases where it is acceptable for those frames, particularly for the multi-destination case, to be discarded or not egressed by any RBridges that do not implement the extended flag.
これらのフレーム、特に複数の宛先の場合、拡張フラグを実装しないRBridgeによって破棄または出力されないことが許容される場合があるため、「SHOULD NOT」が上記で指定されています。
If any extensions are present in a TRILL Header, as indicated by a non-zero Op-Length field, the first 32 bits of the extensions area consist of extended header flags, as described below. The remainder of the extensions area, if any, after the initial 32 bits may be specified in later documents, for example, [Options] and [Options2].
ゼロ以外のOp-Lengthフィールドで示されるように、拡張がTRILLヘッダーに存在する場合、拡張領域の最初の32ビットは、以下で説明するように拡張ヘッダーフラグで構成されます。最初の32ビットの後の拡張領域の残りは、もしあれば、[Options]や[Options2]など、後のドキュメントで指定できます。
Any RBridge adding an extensions area to a TRILL Header must set the first 32 bits to zero except when permitted or required to set one or more of those bits as specified. For TRILL Data frames with extensions present, any transit RBridge that does not discard the frame MUST transparently copy the extended flags word, except for modifications permitted by an extension implemented by that RBridge.
TRILLヘッダーに拡張領域を追加するRBridgeは、最初の32ビットをゼロに設定する必要があります。ただし、許可されている場合、または指定されたビットを1つ以上設定する必要がある場合は除きます。拡張が存在するTRILLデータフレームの場合、フレームを破棄しないトランジットRBridgeは、そのRBridgeによって実装された拡張によって許可された変更を除いて、拡張フラグワードを透過的にコピーする必要があります。
The extended header flags word is illustrated below and the meanings of these bits is further described in the list following the figure.
拡張ヘッダーフラグワードを以下に示し、これらのビットの意味については、図に続くリストでさらに説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension |
| possibly including TLV extensions ...
(The first two critical summary bits are as specified in [RFC6325].
In this document, an "S", for Summary, has been added at the end of
their acronyms. A third critical summary bit is also specified
herein and its acronym also ends with an "S" for consistency.)
Bits Description
--------------------
0-2 Crit.: Critical summary bits. 0 CHbHS: Critical Hop-by-Hop extension(s) are present. 1 CItES: Critical Ingress-to-Egress extension(s) are present. 2 CRSVS: Critical Reserved extension(s) are present.
0-2 Crit .:クリティカルサマリビット。 0 CHbHS：クリティカルホップバイホップ拡張が存在します。 1 CItES：重要な入力から出力への拡張が存在します。 2 CRSVS：Critical Reserved Extension（s）が存在します。
3-7 CHbH: Critical Hop-by-Hop extended flag bits. 8-13 NCHbH: Non-critical Hop-by-Hop extended flag bits.
3-7 CHbH：クリティカルホップバイホップ拡張フラグビット。 8-13 NCHbH：重要でないホップバイホップ拡張フラグビット。
14-16 CRSV: Critical Reserved extended flag bits. 17-20 NCRSV: Non-critical Reserved extended flag bits.
14-16 CTS V：Critical Reserved拡張フラグビット。 17-20 NRSV：重要でない予約済み拡張フラグビット。
21-26 CItE: Critical Ingress-to-Egress extended flag bits. 27-31 NCItE: Non-critical Ingress-to-Egress extended flag bits.
21-26 CItE：重要な入力から出力への拡張フラグビット。 27-31 NCItE：重要でないIngress-to-Egress拡張フラグビット。
The top three bits of the extended header flags area, bits 0, 1, and 2 above, are called the critical summary bits. They summarize the presence of critical extensions as follows:
拡張ヘッダーフラグ領域の上位3ビット、上記のビット0、1、および2は、クリティカルサマリービットと呼ばれます。重要な拡張機能の存在を次のようにまとめています。
CHbHS: If the CHbHS (Critical Hop-by-Hop Summary) bit is one, one or more critical hop-by-hop extensions are present. These might be critical hop-by-hop extended header flags or critical hop-by-hop extensions after the first word in the extensions area. Transit RBridges that do not support all of the critical hop-by-hop extensions present, for example, an RBridge that supported no critical hop-by-hop extensions, MUST drop the frame. If the CHbHS bit is zero, the frame is safe, from the point of view of extensions processing, for a transit RBridge to forward, regardless of what extensions that RBridge does or does not support.
CHbHS：CHbHS（クリティカルホップバイホップサマリー）ビットが1の場合、1つ以上のクリティカルホップバイホップ拡張が存在します。これらは、重要なホップバイホップ拡張ヘッダーフラグ、または拡張領域の最初の単語の後の重要なホップバイホップ拡張である可能性があります。存在する重要なホップバイホップ拡張のすべてをサポートしていない中継RBridge、たとえば、重要なホップバイホップ拡張をサポートしていないRBridgeは、フレームをドロップする必要があります。 CHbHSビットが0の場合、拡張処理の観点からは、RBridgeがサポートする、またはサポートしない拡張に関係なく、中継RBridgeが転送するフレームは安全です。
CItES: If the CItES (Critical Ingress-to-Egress Summary) bit is a one, one or more critical ingress-to-egress extensions are present. These might be critical ingress-to-egress extended header flags or critical ingress-to-egress extensions after the first word in the extensions area. If the CItES bit is zero, no such extensions are present. If either CHbHS or CItES is non-zero, egress RBridges that do not support all critical extensions present, for example, an RBridge that supports no critical extensions, MUST drop the frame. If both CHbHS and CItES are zero, the frame is safe, from the point of view of extensions, for an egress RBridge to process, regardless of what extensions that RBridge does or does not support.
CItES：CItES（Critical Ingress-to-Egress Summary）ビットが1の場合、1つ以上の重要な入力から出力への拡張が存在します。これらは、重要な入力から出力への拡張ヘッダーフラグ、または拡張領域の最初の単語の後の重要な入力から出力への拡張である可能性があります。 CItESビットがゼロの場合、そのような拡張はありません。 CHbHSまたはCItESのいずれかがゼロでない場合、存在するすべてのクリティカル拡張をサポートしない出力RBridge、たとえば、クリティカル拡張をサポートしないRBridgeは、フレームをドロップする必要があります。 CHbHSとCItESの両方がゼロの場合、拡張機能の観点から、RBridgeがサポートする、またはサポートしない拡張機能に関係なく、出力RBridgeが処理するフレームは安全です。
CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or more critical extensions are present that are reserved to apply to a class of RBridges to be specified in the future, for example, border RBridges in a TRILL campus extended to support multi-level IS-IS. This class will be a subset of transit RBridges. RBridges in this class MUST drop frames with the CRSVS bit set unless they implement all critical hop-by-hop and all critical reserved extensions present in the frame.
CRSVS：CRSVS（Critical Reserved Summary）ビットが1の場合、将来指定されるRBridgeのクラスに適用するために予約されている1つ以上のクリティカル拡張が存在します。たとえば、拡張されたTRILLキャンパスの境界RBridgeマルチレベルIS-ISをサポートします。このクラスは、トランジットRBridgeのサブセットになります。このクラスのRBridgeは、フレーム内に存在するすべての重要なホップバイホップおよびすべての重要な予約済み拡張を実装しない限り、CRSVSビットが設定されたフレームをドロップする必要があります。
The critical summary bits enable simple and efficient processing of TRILL Data frames by egress RBridges that support no critical extensions, by transit RBridges that support no critical hop-by-hop extensions, and by RBridges in the reserved class that support no critical hop-by-hop or reserved extensions. Such RBridges need only check whether Op-Length is non-zero and, if it is, check the top one, two, or three bits just after the fixed portion of the TRILL Header. Based on those three bits, such RBridges can decide whether to discard or forward/process the frame.
クリティカルサマリビットは、クリティカル拡張をサポートしない出力RBridge、クリティカルホップバイホップ拡張をサポートしないトランジットRBridge、およびクリティカルホップバイをサポートしない予約済みクラスのRBridgeによる、TRILLデータフレームのシンプルで効率的な処理を可能にします。 -hopまたは予約済みの拡張機能。このようなRBridgeは、Op-Lengthがゼロ以外であるかどうかを確認するだけでよく、ゼロの場合は、TRILLヘッダーの固定部分の直後の上位1、2、または3ビットを確認します。これらの3ビットに基づいて、そのようなRBridgeはフレームを破棄するか、転送/処理するかを決定できます。
Defining TRILL extensions including extended header flags that conflict with each other would be undesirable. Should conflicting extensions appear in the same packet, the results would be unpredictable if different implementations processed them in different orders. While rules could be defined to specify how to predictably process conflicting extensions, such rules would also limit implementation flexibility and could impose substantial processing burdens.
互いに競合する拡張ヘッダーフラグを含むTRILL拡張を定義することは望ましくありません。競合する拡張機能が同じパケットに現れる場合、異なる実装が異なる順序でそれらを処理した場合、結果は予測できません。競合する拡張機能を予測可能に処理する方法を指定するルールを定義できますが、そのようなルールは実装の柔軟性を制限し、かなりの処理負荷を課す可能性があります。
Conflicting extensions SHOULD NOT be defined, but if they are, careful thought should be given as to whether and how to specify the handling of conflicting extensions.
競合する拡張機能は定義すべきではありません（SHOULD NOT）が、定義されている場合は、競合する拡張機能の処理を指定するかどうか、およびその指定方法について慎重に検討する必要があります。
The table below shows the state of TRILL Header extended flag assignments. See Section 5 for IANA Considerations.
以下の表は、TRILLヘッダー拡張フラグ割り当ての状態を示しています。 IANAの考慮事項については、セクション5を参照してください。
Bits Purpose Section
----------------------------------------------------------------
0-2 Critical Summary Bits 2.3.1
3-6 available critical hop-by-hop flags
7 Critical Channel Alert flag 3.1
8 Non-critical Channel Alert flag 3.1
9-13 available non-critical hop-by-hop flags
14-16 available critical reserved flags
17-20 available non-critical reserved flags
21-26 available critical ingress-to-egress flags
27-31 available non-critical ingress-to-egress flags
Table 1: Extended Header Flags Area
表1：拡張ヘッダーフラグ領域
The RBridge Channel Alert extended header flags indicate that the frame is an RBridge Channel frame [RFC7178] that requests processing at each hop.
RBridge Channel Alert拡張ヘッダーフラグは、フレームが各ホップでの処理を要求するRBridge Channelフレーム[RFC7178]であることを示します。
If the Critical Channel Alert flag (bit 7) is a one and the RBridge does not implement the RBridge Channel feature or the particular RBridge Channel protocol involved [RFC7178] or the frame does not actually appear to be an RBridge Channel message, then the frame is discarded. This permits implementation, for example, of a channel message requiring strict source routing or the like, with assurance that it will be discarded rather than deviate from the directed path.
クリティカルチャネルアラートフラグ（ビット7）が1であり、RBridgeがRBridgeチャネル機能または関連する特定のRBridgeチャネルプロトコルを実装していない場合[RFC7178]、またはフレームが実際にはRBridgeチャネルメッセージであるように見えない場合、フレーム破棄されます。これにより、たとえば、厳密なソースルーティングなどを必要とするチャネルメッセージの実装が可能になり、有向パスから逸脱するのではなく破棄されることが保証されます。
If the frame is not discarded as described above, then the presence of either the Critical or Non-critical Channel Alert flag alerts transit RBridges to the presence of an RBridge Channel message [RFC7178] that may require special handling. The non-critical alert flag supports, for example, an RBridge Channel protocol message including a "record route" function where not recording transit RBridges that do not support this function is acceptable.
上記のようにフレームが破棄されない場合、クリティカルまたは非クリティカルチャネルアラートフラグが存在すると、トランジットRBridgeに、特別な処理が必要なRBridgeチャネルメッセージ[RFC7178]が存在することを警告します。非クリティカルアラートフラグは、たとえば、「ルートの記録」機能を含むRBridge Channelプロトコルメッセージをサポートします。この機能では、この機能をサポートしない通過RBridgeを記録しないことが許容されます。
RBridges use IS-IS Link State PDUs (LSPs) to inform other RBridges which extended header flags they support. The IS-IS PDU(s), TLV(s), or sub-TLV(s) used to encode and advertise this information are specified in a separate document [RFC7176].
RBridgeはIS-ISリンクステートPDU（LSP）を使用して、サポートする拡張ヘッダーフラグを他のRBridgeに通知します。この情報のエンコードとアドバタイズに使用されるIS-IS PDU、TLV、またはサブTLVは、別のドキュメント[RFC7176]で指定されています。
IANA has created a "TRILL Extended Header Flags" subregistry within the TRILL Parameters registry. The "TRILL Extended Header Flags" subregistry is initially populated as specified in Table 1 in Section 3. References in that table to sections of this document have been replaced in the IANA subregistry by references to this document as an RFC.
IANAは、TRILLパラメータレジストリ内に「TRILL拡張ヘッダーフラグ」サブレジストリを作成しました。 「TRILL Extended Header Flags」サブレジストリは、最初にセクション3の表1で指定されているように入力されます。このドキュメントのセクションへのそのテーブル内の参照は、RFCとしてのこのドキュメントへの参照によってIANAサブレジストリで置き換えられました。
New TRILL extended header flags are allocated by IETF Review [RFC5226].
新しいTRILL拡張ヘッダーフラグは、IETFレビュー[RFC5226]によって割り当てられます。
To indicate support of extended header flags, IANA has assigned the following bits in the TRILL-VER and PORT-TRILL-VER Sub-TLV Capability Flag registries created by [RFC7176]:
拡張ヘッダーフラグのサポートを示すために、IANAは[RFC7176]によって作成されたTRILL-VERおよびPORT-TRILL-VER Sub-TLV機能フラグレジストリに次のビットを割り当てました。
o Bits 3-13 of the PORT-TRILL-VER Sub-TLV Capability Flags have been assigned to indicate support of TRILL hop-by-hop extended header flags 3-13.
o PORT-TRILL-VERサブTLV機能フラグのビット3〜13は、TRILLホップバイホップ拡張ヘッダーフラグ3〜13のサポートを示すために割り当てられています。
o Bits 14-31 of the TRILL-VER Sub-TLV Capability Flags have been assigned to indicate support of TRILL extended header flags 14-31.
o TRILL-VERサブTLV機能フラグのビット14〜31は、TRILL拡張ヘッダーフラグ14〜31のサポートを示すために割り当てられています。
For general TRILL protocol security considerations, see [RFC6325].
TRILLプロトコルのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
For security considerations related to extended header flags, see the document where the flag is specified.
拡張ヘッダーフラグに関連するセキュリティの考慮事項については、フラグが指定されているドキュメントを参照してください。
It is important that the critical summary bits in the extended header flags word be set properly. If set when critical extensions of the appropriate category are not present, frames may be unnecessarily discarded. If not set when critical extensions are present, frames may be mishandled or corrupted, and intended security policies may be violated.
拡張ヘッダーフラグワードのクリティカルサマリビットが適切に設定されていることが重要です。適切なカテゴリの重要な拡張が存在しないときに設定すると、フレームが不必要に破棄される可能性があります。重要な拡張機能が存在するときに設定されていない場合、フレームが誤って処理されたり破損したりする可能性があり、意図したセキュリティポリシーに違反する可能性があります。
The RBridge Channel Alert extended header flags have the following security considerations. Implementations should keep in mind that they might be erroneously set in a frame. If either RBridge Channel Alert flag is found set in a frame that is not an RBridge Channel message [RFC7178], the flag MAY be cleared and should have no effect except, possibly, delaying processing of the frame. If either RBridge Channel Alert flag is erroneously omitted from a frame, desired per-hop processing for the frame may not occur.
RBridge Channel Alert拡張ヘッダーフラグには、次のセキュリティ上の考慮事項があります。実装では、フレームに誤って設定される可能性があることに注意してください。いずれかのRBridge Channel AlertフラグがRBridge Channelメッセージ[RFC7178]ではないフレームで設定されていることが検出された場合、フラグはクリアされる場合があり、フレームの処理を遅らせる以外は効果がないはずです。どちらかのRBridge Channel Alertフラグが誤ってフレームから省略されている場合、フレームに必要なホップごとの処理が行われない可能性があります。
The following, listed in alphabetic order, are thanked for their valuable contributions: Ben Campbell, Adrian Farrel, Barry Leiba, and Thomas Narten.
アルファベット順でリストされた次のものは、それらの貴重な貢献に感謝しています：ベンキャンベル、エイドリアンファレル、バリーレイバ、トーマスナルテン。
[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月。
[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月。
[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。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、May 2014 。
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[MultiLevel] Perlman、R.、Eastlake 3rd、D.、Ghanwani、A。、およびH. Zhai、「Flexible Multilevel TRILL（Transparent Interconnection of Lots of Links）」、進行中の作業、2014年1月。
[Options] Eastlake 3rd, D., Ghanwani, A., Manral, V., and C. Bestler, "RBridges: Further TRILL Header Extensions", Work in Progress, June 2012.
[オプション] Eastlake 3rd、D.、Gwanwani、A.、Manral、V。、およびC. Bestler、「RBridges：さらにTRILLヘッダー拡張」、Work in Progress、2012年6月。
[Options2] Eastlake 3rd, D., "RBridges: More Proposed TRILL Header Options", Work in Progress, October 2011.
[Options2] Eastlake 3rd、D。、「RBridges：More Proposed TRILL Header Options」、Work in Progress、2011年10月。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク3rd Huawei R＆D USA 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054 USA
EMail: anoop@alumni.duke.edu
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 95117彼
EMail: vishwas@ionosnetworks.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Caitlin Bestler Nexenta Systems 455 El Camino Real Santa Clara, CA 95050 USA
Caitlin Bestler Nexenta Systems 455 El Camino Real Santa Clara、CA 95050 USA
EMail: caitlin.bestler@nexenta.com