[要約] RFC 8013は、ForCESアーキテクチャにおけるInter-FE LFBの機能と目的を定義しています。このRFCの目的は、ネットワーク機器の転送機能と制御機能を分離し、柔軟性とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) D. Joachimpillai
Request for Comments: 8013 Verizon
Category: Standards Track J. Hadi Salim
ISSN: 2070-1721 Mojatatu Networks
February 2017
Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)
転送と制御要素分離（ForCES）FE間論理機能ブロック（LFB）
Abstract
概要
This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class. The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification. The document focuses on Ethernet transport.
このドキュメントでは、FE間LFBクラスを定義することにより、転送および制御要素分離（ForCES）論理機能ブロック（LFB）トポロジを転送要素（FE）全体に拡張する方法について説明します。 FE間LFBクラスは、ForCES仕様に変更を加えることなく、FE間でデータとメタデータを渡す機能を提供します。このドキュメントでは、イーサネットトランスポートに焦点を当てています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8013.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8013で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope and Use Cases . . . . . . . . . . . . . . . . . 4
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Basic IPv4 Router . . . . . . . . . . . . . . . . . . 4
3.2.1.1. Distributing the Basic IPv4 Router . . . . . . . 6
3.2.2. Arbitrary Network Function . . . . . . . . . . . . . 7
3.2.2.1. Distributing the Arbitrary Network Function . . . 8
4. Inter-FE LFB Overview . . . . . . . . . . . . . . . . . . . . 8
4.1. Inserting the Inter-FE LFB . . . . . . . . . . . . . . . 8
5. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . . 10
5.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . . . 10
5.1.1. MTU Consideration . . . . . . . . . . . . . . . . . . 10
5.1.2. Quality-of-Service Considerations . . . . . . . . . . 11
5.1.3. Congestion Considerations . . . . . . . . . . . . . . 11
5.2. Inter-FE Ethernet Encapsulation . . . . . . . . . . . . . 12
6. Detailed Description of the Ethernet Inter-FE LFB . . . . . . 13
6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 14
6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . 15
6.2. Components . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. IEEE Assignment Considerations . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
In the ForCES architecture, a packet service can be modeled by composing a graph of one or more LFB instances. The reader is referred to the details in the ForCES model [RFC5812].
ForCESアーキテクチャでは、パケットサービスは、1つ以上のLFBインスタンスのグラフを作成することによってモデル化できます。読者は、ForCESモデル[RFC5812]の詳細を参照されます。
The ForCES model describes the processing within a single Forwarding Element (FE) in terms of Logical Functional Blocks (LFBs), including provision for the Control Element (CE) to establish and modify that processing sequence, and the parameters of the individual LFBs.
ForCESモデルは、論理転送ブロック（LFB）の観点から単一の転送要素（FE）内の処理を記述します。これには、制御要素（CE）がその処理シーケンスを確立および変更するためのプロビジョニング、および個々のLFBのパラメーターが含まれます。
Under some circumstances, it would be beneficial to be able to extend this view and the resulting processing across more than one FE. This may be in order to achieve scale by splitting the processing across elements or to utilize specialized hardware available on specific FEs.
状況によっては、このビューとその結果の処理を複数のFEに拡張できると便利です。これは、要素間で処理を分割してスケールを達成するため、または特定のFEで利用可能な専用ハードウェアを利用するためです。
Given that the ForCES inter-LFB architecture calls for the ability to pass metadata between LFBs, it is imperative to define mechanisms to extend that existing feature and allow passing the metadata between LFBs across FEs.
ForCESのLFB間アーキテクチャでは、LFB間でメタデータを受け渡す機能が必要であるため、その既存の機能を拡張し、FE間でLFB間でメタデータを受け渡すことができるメカニズムを定義することが不可欠です。
This document describes how to extend the LFB topology across FEs, i.e., inter-FE connectivity without needing any changes to the ForCES definitions. It focuses on using Ethernet as the interconnection between FEs.
このドキュメントでは、ForCESの定義を変更せずに、FE間でLFBトポロジを拡張する方法、つまりFE間接続を説明します。 FE間の相互接続としてイーサネットを使用することに焦点を当てています。
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]で説明されているように解釈されます。
This document depends on the terms (below) defined in several ForCES documents: [RFC3746], [RFC5810], [RFC5811], [RFC5812], [RFC7391], and [RFC7408].
このドキュメントは、[RFC3746]、[RFC5810]、[RFC5811]、[RFC5812]、[RFC7391]、および[RFC7408]のいくつかのForCESドキュメントで定義されている用語（以下）に依存しています。
Control Element (CE)
制御要素（CE）
Forwarding Element (FE)
転送要素（FE）
FE Model
モデルで
LFB (Logical Functional Block) Class (or type)
LFB（論理機能ブロック）クラス（またはタイプ）
LFB Instance
LFBインスタンス
LFB Model
LFBモデル
LFB Metadata
LFBメタデータ
ForCES Component
ForCESコンポーネント
LFB Component ForCES Protocol Layer (ForCES PL)
LFBコンポーネントForCESプロトコル層（ForCES PL）
ForCES Protocol Transport Mapping Layer (ForCES TML)
ForCESプロトコルトランスポートマッピングレイヤー（ForCES TML）
The scope of this document is to solve the challenge of passing ForCES-defined metadata alongside packet data across FEs (be they physical or virtual) for the purpose of distributing the LFB processing.
このドキュメントの範囲は、LFB処理を分散する目的で、ForCESで定義されたメタデータをパケットデータと共にFE（物理または仮想）全体に渡すという課題を解決することです。
o The FEs involved in the inter-FE LFB belong to the same Network Element (NE) and are within a single administrative private network that is in close proximity.
o FE間LFBに含まれるFEは同じネットワークエレメント（NE）に属し、近接している単一の管理プライベートネットワーク内にあります。
o The FEs are already interconnected using Ethernet. We focus on Ethernet because it is commonly used for FE interconnection. Other higher transports (such as UDP over IP) or lower transports could be defined to carry the data and metadata, but these cases are not addressed in this document.
o FEはすでにイーサネットを使用して相互接続されています。イーサネットはFE相互接続に一般的に使用されるため、イーサネットに焦点を当てています。他の上位のトランスポート（UDP over IPなど）または下位のトランスポートは、データとメタデータを運ぶように定義できますが、これらのケースはこのドキュメントでは扱いません。
To illustrate the problem scope, we present two use cases where we start with a single FE running all the LFBs functionality and then split it into multiple FEs achieving the same end goals.
問題の範囲を説明するために、すべてのLFB機能を実行する単一のFEから始めて、それを同じ最終目標を達成する複数のFEに分割する2つの使用例を示します。
A sample LFB topology depicted in Figure 1 demonstrates a service graph for delivering a basic IPv4-forwarding service within one FE. For the purpose of illustration, the diagram shows LFB classes as graph nodes instead of multiple LFB class instances.
図1に示すサンプルLFBトポロジは、1つのFE内で基本的なIPv4転送サービスを提供するためのサービスグラフを示しています。説明のために、この図ではLFBクラスを複数のLFBクラスインスタンスではなくグラフノードとして示しています。
Since the purpose of the illustration in Figure 1 is to showcase how data and metadata are sent down or upstream on a graph of LFB instances, it abstracts out any ports in both directions and talks about a generic ingress and egress LFB. Again, for illustration purposes, the diagram does not show exception or error paths. Also left out are details on Reverse Path Filtering, ECMP, multicast handling, etc. In other words, this is not meant to be a complete description of an IPv4-forwarding application; for a more complete example, please refer to the LFBLibrary document [RFC6956].
図1の図の目的は、データとメタデータがLFBインスタンスのグラフ上でダウンストリームまたはアップストリームに送信される方法を示すことであるため、双方向のポートを抽象化し、一般的な入力および出力LFBについて説明します。繰り返しになりますが、説明のために、ダイアグラムには例外パスやエラーパスは示されていません。リバースパスフィルタリング、ECMP、マルチキャスト処理などの詳細も省略されています。つまり、これはIPv4転送アプリケーションの完全な説明ではありません。より完全な例については、LFBLibraryドキュメント[RFC6956]を参照してください。
The output of the ingress LFB(s) coming into the IPv4 Validator LFB will have both the IPv4 packets and, depending on the implementation, a variety of ingress metadata such as offsets into the different headers, any classification metadata, physical and virtual ports encountered, tunneling information, etc. These metadata are lumped together as "ingress metadata".
IPv4 Validator LFBに入る入力LFBの出力には、IPv4パケットと、実装に応じて、さまざまなヘッダーへのオフセット、分類メタデータ、遭遇した物理ポートと仮想ポートなどのさまざまな入力メタデータの両方が含まれます、トンネリング情報など。これらのメタデータは「入力メタデータ」としてまとめられます。
Once the IPv4 validator vets the packet (for example, it ensures that there is no expired TTL), it feeds the packet and inherited metadata into the IPv4 unicast LPM (Longest-Prefix-Matching) LFB.
IPv4バリデーターがパケットを検証すると（たとえば、有効期限切れのTTLがないことが保証されます）、パケットと継承されたメタデータがIPv4ユニキャストLPM（Longest-Prefix-Matching）LFBに送られます。
+----+
| |
IPv4 pkt | | IPv4 pkt +-----+ +---+
+------------->| +------------->| | | |
| + ingress | | + ingress |IPv4 | IPv4 pkt | |
| metadata | | metadata |Ucast+------------>| +--+
| +----+ |LPM | + ingress | | |
+-+-+ IPv4 +-----+ + NHinfo +---+ |
| | Validator metadata IPv4 |
| | LFB NextHop|
| | LFB |
| | |
| | IPv4 pkt |
| | + {ingress |
+---+ + NHdetails}
Ingress metadata |
LFB +--------+ |
| Egress | |
<--+ |<-----------------+
| LFB |
+--------+
Figure 1: Basic IPv4 Packet Service LFB Topology
図1：基本的なIPv4パケットサービスLFBトポロジ
The IPv4 unicast LPM LFB does an LPM lookup on the IPv4 FIB using the destination IP address as a search key. The result is typically a next-hop selector, which is passed downstream as metadata.
IPv4ユニキャストLPM LFBは、宛先IPアドレスを検索キーとして使用して、IPv4 FIBでLPMルックアップを実行します。結果は、通常、メタデータとしてダウンストリームに渡されるネクストホップセレクターです。
The NextHop LFB receives the IPv4 packet with associated next-hop (NH) information metadata. The NextHop LFB consumes the NH information metadata and derives a table index from it to look up the next-hop table in order to find the appropriate egress information. The lookup result is used to build the next-hop details to be used downstream on the egress. This information may include any source and destination information (for our purposes, which Media Access Control (MAC) addresses to use) as well as egress ports. (Note: It is also at this LFB where typically, the forwarding TTL-decrementing and IP checksum recalculation occurs.) The details of the egress LFB are considered out of scope for this discussion. Suffice it to say that somewhere within or beyond the Egress LFB, the IPv4 packet will be sent out a port (e.g., Ethernet, virtual or physical).
NextHop LFBは、ネクストホップ（NH）情報メタデータが関連付けられたIPv4パケットを受信します。 NextHop LFBはNH情報メタデータを使用し、そこからテーブルインデックスを導出して、適切な出力情報を見つけるためにネクストホップテーブルを検索します。ルックアップ結果は、下りの下りで使用されるネクストホップの詳細を構築するために使用されます。この情報には、送信元と宛先の情報（ここでは、目的のメディアアクセスコントロール（MAC）アドレスを使用する）と出力ポートが含まれます。 （注：このLFBでも、通常、転送TTLデクリメントとIPチェックサムの再計算が行われます。）出力LFBの詳細は、この説明の範囲外と見なされます。出力LFBの内部または外部のどこかで、IPv4パケットがポート（たとえば、イーサネット、仮想、または物理）から送信されると言うだけで十分です。
Figure 2 demonstrates one way that the router LFB topology in Figure 1 may be split across two FEs (e.g., two Application-Specific Integrated Circuits (ASICs)). Figure 2 shows the LFB topology split across FEs after the IPv4 unicast LPM LFB.
図2は、図1のルーターLFBトポロジが2つのFE（たとえば、2つの特定用途向け集積回路（ASIC））に分割される1つの方法を示しています。図2は、IPv4ユニキャストLPM LFBの後にFE間で分割されたLFBトポロジを示しています。
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| LFB | |
+---------------------------------------------------|---------+
|
IPv4 packet +
{ingress + NHinfo}
metadata
FE2 |
+---------------------------------------------------|---------+
| V |
| +--------+ +--------+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+
Figure 2: Split IPv4 Packet Service LFB Topology
図2：分割IPv4パケットサービスLFBトポロジ
Some proprietary interconnections (for example, Broadcom HiGig over XAUI [brcm-higig]) are known to exist to carry both the IPv4 packet and the related metadata between the IPv4 Unicast LFB and IPv4NextHop LFB across the two FEs.
2つのFE間でIPv4ユニキャストLFBとIPv4NextHop LFBの間でIPv4パケットと関連メタデータの両方を伝送するために、いくつかの独自の相互接続（たとえば、Broadcom HiGig over XAUI [brcm-higig]）が存在することが知られています。
This document defines the inter-FE LFB, a standard mechanism for encapsulating, generating, receiving, and decapsulating packets and associated metadata FEs over Ethernet.
このドキュメントでは、イーサネット上のパケットおよび関連するメタデータFEをカプセル化、生成、受信、カプセル化解除するための標準的なメカニズムであるinter-FE LFBを定義します。
In this section, we show an example of an arbitrary Network Function that is more coarsely grained in terms of functionality. Each Network Function may constitute more than one LFB.
このセクションでは、機能の点でより粗い任意のネットワーク関数の例を示します。各ネットワーク機能は、複数のLFBを構成する場合があります。
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Network | pkt |NF2 | pkt +-----+ |
| | Function +-------------->| +------------->| | |
| | 1 | + NF1 | | + NF1/2 |NF3 | |
| +----------+ metadata | | metadata | | |
| ^ +----+ | | |
| | +--+--+ |
| | | |
| | |
+---------------------------------------------------|---------+
V
Figure 3: A Network Function Service Chain within One FE
図3：1つのFE内のネットワーク機能サービスチェーン
The setup in Figure 3 is typical of most packet processing boxes where we have functions like deep packet inspection (DPI), NAT, Routing, etc., connected in such a topology to deliver a packet processing service to flows.
図3のセットアップは、ディープパケットインスペクション（DPI）、NAT、ルーティングなどの機能がフローにパケット処理サービスを提供するトポロジーで接続されているほとんどのパケット処理ボックスの典型です。
The setup in Figure 3 can be split across three FEs instead of as demonstrated in Figure 4. This could be motivated by scale-out reasons or because different vendors provide different functionality, which is plugged-in to provide such functionality. The end result is having the same packet service delivered to the different flows passing through.
図3のセットアップは、図4に示すように3つのFEに分割できます。これは、スケールアウトの理由、または異なるベンダーが異なる機能を提供しているため、プラグインされてそのような機能が提供されるためです。その結果、通過する異なるフローに同じパケットサービスが配信されます。
FE1 FE2
+----------+ +----+ FE3
| Network | pkt |NF2 | pkt +-----+
| Function +-------------->| +------------->| |
| 1 | + NF1 | | + NF1/2 |NF3 |
+----------+ metadata | | metadata | |
^ +----+ | |
| +--+--+
|
V
Figure 4: A Network Function Service Chain Distributed across Multiple FEs
図4：複数のFEに分散されたネットワーク機能サービスチェーン
We address the inter-FE connectivity requirements by defining the inter-FE LFB class. Using a standard LFB class definition implies no change to the basic ForCES architecture in the form of the core LFBs (FE Protocol or Object LFBs). This design choice was made after considering an alternative approach that would have required changes to both the FE Object capabilities (SupportedLFBs) and the LFBTopology component to describe the inter-FE connectivity capabilities as well as the runtime topology of the LFB instances.
FE間のLFBクラスを定義することにより、FE間の接続要件に対処します。標準のLFBクラス定義を使用しても、コアLFB（FEプロトコルまたはオブジェクトLFB）の形式で基本的なForCESアーキテクチャが変更されることはありません。この設計の選択は、FEオブジェクトの機能（SupportedLFB）とLFBTopologyコンポーネントの両方に変更を加えて、FEB間の接続機能とLFBインスタンスのランタイムトポロジを説明する必要がある代替アプローチを検討した後に行われました。
The distributed LFB topology described in Figure 2 is re-illustrated in Figure 5 to show the topology location where the inter-FE LFB would fit in.
図2で説明されている分散LFBトポロジは、図5で再図示されており、FE間LFBが適合するトポロジの場所を示しています。
As can be observed in Figure 5, the same details passed between IPv4 unicast LPM LFB and the IPv4 NH LFB are passed to the egress side of the inter-FE LFB. This information is illustrated as multiplicity of inputs into the egress inter-FE LFB instance. Each input represents a unique set of selection information.
図5からわかるように、IPv4ユニキャストLPM LFBとIPv4 NH LFBの間で渡される同じ詳細が、インターFE LFBの出力側に渡されます。この情報は、出力FE間LFBインスタンスへの入力の多様性として示されています。各入力は、選択情報の一意のセットを表します。
FE1
+-------------------------------------------------------------+
| +----------+ +----+ |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| | LFB | |
| | IPv4 pkt + metadata |
| | {ingress + NHinfo} |
| | | |
| | +..--+..+ |
| | |..| | | |
| +-V--V-V--V-+ |
| | Egress | |
| | Inter-FE | |
| | LFB | |
| +------+----+ |
+---------------------------------------------------|---------+
|
Ethernet Frame with: |
IPv4 packet data and metadata
{ingress + NHinfo + Inter-FE info}
FE2 |
+---------------------------------------------------|---------+
| +..+.+..+ |
| |..|.|..| |
| +-V--V-V--V-+ |
| | Ingress | |
| | Inter-FE | |
| | LFB | |
| +----+------+ |
| | |
| IPv4 pkt + metadata |
| {ingress + NHinfo} |
| | |
| +--------+ +----V---+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+
Figure 5: Split IPv4-Forwarding Service with Inter-FE LFB
図5：Inter-FE LFBを使用したIPv4転送サービスの分割
The egress of the inter-FE LFB uses the received packet and metadata to select details for encapsulation when sending messages towards the selected neighboring FE. These details include what to communicate as the source and destination FEs (abstracted as MAC addresses as described in Section 5.2); in addition, the original metadata may be passed along with the original IPv4 packet.
FE間LFBの出力は、受信したパケットとメタデータを使用して、選択した隣接FEにメッセージを送信するときにカプセル化の詳細を選択します。これらの詳細には、送信元および宛先FEとして何を通信するかが含まれます（セクション5.2で説明されているように、MACアドレスとして抽出されます）。さらに、元のメタデータが元のIPv4パケットと共に渡される場合があります。
On the ingress side of the inter-FE LFB, the received packet and its associated metadata are used to decide the packet graph continuation. This includes which of the original metadata and on which next LFB class instance to continue processing. In Figure 5, an IPv4NextHop LFB instance is selected and the appropriate metadata is passed to it.
FE間LFBの入力側では、受信したパケットとそれに関連するメタデータを使用して、パケットグラフの継続を決定します。これには、元のメタデータのどれと、処理を続行する次のLFBクラスインスタンスが含まれます。図5では、IPv4NextHop LFBインスタンスが選択され、適切なメタデータがそれに渡されています。
The ingress side of the inter-FE LFB consumes some of the information passed and passes it the IPv4 packet alongside with the ingress and NHinfo metadata to the IPv4NextHop LFB as was done earlier in both Figures 1 and 2.
インターFE LFBの入力側は、渡された情報の一部を消費し、図1と2の両方で以前に行われたように、IPv4パケットを入力とNHinfoメタデータと共にIPv4NextHop LFBに渡します。
Section 5.1 describes some of the issues related to using Ethernet as the transport and how we mitigate them.
セクション5.1では、トランスポートとしてのイーサネットの使用に関連するいくつかの問題と、それらを軽減する方法について説明します。
Section 5.2 defines a payload format that is to be used over Ethernet. An existing implementation of this specification that runs on top of Linux Traffic Control [linux-tc] is described in [tc-ife].
セクション5.2では、イーサネットで使用されるペイロード形式を定義しています。 Linux Traffic Control [linux-tc]上で実行されるこの仕様の既存の実装は、[tc-ife]で説明されています。
There are several issues that may occur due to using direct Ethernet encapsulation that need consideration.
直接イーサネットカプセル化の使用が原因で発生する可能性のある問題がいくつかあります。
Because we are adding data to existing Ethernet frames, MTU issues may arise. We recommend:
既存のイーサネットフレームにデータを追加しているため、MTUの問題が発生する可能性があります。以下をお勧めします：
o Using large MTUs when possible (example with jumbo frames).
o 可能な場合は大きなMTUを使用します（ジャンボフレームの例）。
o Limiting the amount of metadata that could be transmitted; our definition allows for filtering of select metadata to be encapsulated in the frame as described in Section 6. We recommend sizing the egress port MTU so as to allow space for maximum size of the metadata total size to allow between FEs. In such a setup, the port is configured to "lie" to the upper layers by claiming to have a lower MTU than it is capable of. Setting the MTU can be achieved by ForCES control of the port LFB (or some other configuration. In essence, the control plane when explicitly making a decision for the MTU settings of the egress port is implicitly deciding how much metadata will be allowed. Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791] and for IPv6 the minimum size is 1280 octets [RFC2460].
o送信できるメタデータの量を制限する。セクション6で説明するように、この定義により、選択したメタデータのフィルタリングをフレームにカプセル化できます。FE間で許容されるメタデータの合計サイズの最大サイズのスペースを確保できるように、出力ポートMTUのサイズを決定することをお勧めします。そのような設定では、ポートは、MTUが可能なよりも低いMTUを持っていると主張することにより、上位層に「横たわる」ように構成されます。 MTUの設定は、ポートLFB（またはその他の構成）のForCES制御によって実現できます。本質的に、出力ポートのMTU設定を明示的に決定するときのコントロールプレーンは、許可されるメタデータの量を暗黙的に決定します。結果として報告されるリンクMTUがどれほど低くなるかを検討します。IPv4パケットの場合、最小サイズは64オクテット[RFC791]であり、IPv6の場合、最小サイズは1280オクテット[RFC2460]です。
A raw packet arriving at the inter-FE LFB (from upstream LFB class instances) may have Class-of-Service (CoS) metadata indicating how it should be treated from a Quality-of-Service perspective.
（アップストリームLFBクラスインスタンスから）FE間LFBに到着する生パケットには、サービス品質の観点からそれをどのように処理する必要があるかを示すサービスクラス（CoS）メタデータが含まれる場合があります。
The resulting Ethernet frame will be eventually (preferentially) treated by a downstream LFB (typically a port LFB instance) and their CoS marks will be honored in terms of priority. In other words, the presence of the inter-FE LFB does not change the CoS semantics.
結果として得られるイーサネットフレームは、最終的に（優先的に）ダウンストリームLFB（通常はポートLFBインスタンス）によって処理され、それらのCoSマークは優先度の点で尊重されます。つまり、インターFE LFBの存在はCoSセマンティクスを変更しません。
Most of the traffic passing through FEs that utilize the inter-FE LFB is expected to be IP based, which is generally assumed to be congestion controlled [UDP-GUIDE]. For example, if congestion causes a TCP packet annotated with additional ForCES metadata to be dropped between FEs, the sending TCP can be expected to react in the same fashion as if that packet had been dropped at a different point on its path where ForCES is not involved. For this reason, additional inter-FE congestion-control mechanisms are not specified.
FE間LFBを利用するFEを通過するトラフィックのほとんどは、IPベースであると予想されます。これは、通常、輻輳制御されていると想定されています[UDP-GUIDE]。たとえば、輻輳により追加のForCESメタデータで注釈が付けられたTCPパケットがFE間でドロップされる場合、送信TCPは、そのパケットがForCESが存在しないパスの別のポイントでドロップされた場合と同じように反応すると期待できます。関与。このため、追加のFE間の輻輳制御メカニズムは指定されていません。
However, the increased packet size due to the addition of ForCES metadata is likely to require additional bandwidth on inter-FE links in comparison to what would be required to carry the same traffic without ForCES metadata. Therefore, traffic engineering SHOULD be done when deploying inter-FE encapsulation.
ただし、ForCESメタデータの追加によるパケットサイズの増加は、ForCESメタデータなしで同じトラフィックを伝送するために必要なものと比較して、FE間リンクで追加の帯域幅を必要とする可能性があります。したがって、トラフィックエンジニアリングは、FE間のカプセル化を展開するときに行う必要があります。
Furthermore, the inter-FE LFB MUST only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion. These are Controlled Environments, as defined by Section 3.6 of [UDP-GUIDE]. Additional measures SHOULD be imposed to restrict the impact of inter-FE-encapsulated traffic on other traffic; for example:
さらに、FE間LFBは、単一のネットワーク内（単一のネットワークオペレーターを使用）、または渋滞を回避するためにトラフィックが管理される、協力するネットワークオペレーターの隣接セットのネットワーク内にのみ配置する必要があります。これらは、[UDP-GUIDE]のセクション3.6で定義されている、制御された環境です。 FEカプセル化されたトラフィックが他のトラフィックに与える影響を制限するために、追加の対策を課す必要があります。例えば：
o rate-limiting all inter-FE LFB traffic at an upstream LFB
o アップストリームLFBですべてのFE間LFBトラフィックをレート制限する
o managing circuit breaking [circuit-b]
o 回路遮断の管理[circuit-b]
o Isolating the inter-FE traffic either via dedicated interfaces or VLANs
o 専用インターフェイスまたはVLANを介したFE間トラフィックの分離
The Ethernet wire encapsulation is illustrated in Figure 6. The process that leads to this encapsulation is described in Section 6. The resulting frame is 32-bit aligned.
イーサネットワイヤのカプセル化を図6に示します。このカプセル化に至るプロセスについては、セクション6で説明します。結果のフレームは32ビットで整列されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-FE ethertype | Metadata length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original packet data ~~................~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet Format Definition
図6：パケット形式の定義
The Ethernet header (illustrated in Figure 6) has the following semantics:
イーサネットヘッダー（図6に示す）には、次のセマンティクスがあります。
o The Destination MAC Address is used to identify the Destination FEID by the CE policy (as described in Section 6).
o 宛先MACアドレスは、CEポリシーによって宛先FEIDを識別するために使用されます（セクション6で説明）。
o The Source MAC Address is used to identify the Source FEID by the CE policy (as described in Section 6).
o ソースMACアドレスは、CEポリシーによってソースFEIDを識別するために使用されます（セクション6で説明）。
o The ethertype is used to identify the frame as inter-FE LFB type. Ethertype ED3E (base 16) is to be used.
o ethertypeは、フレームをFE間LFBタイプとして識別するために使用されます。 Ethertype ED3E（base 16）を使用します。
o The 16-bit metadata length is used to describe the total encoded metadata length (including the 16 bits used to encode the metadata length).
o 16ビットのメタデータの長さは、エンコードされたメタデータの長さの合計（メタデータの長さのエンコードに使用された16ビットを含む）を記述するために使用されます。
o One or more 16-bit TLV-encoded metadatum follows the Metadata length field. The TLV type identifies the metadata ID. ForCES metadata IDs that have been registered with IANA will be used.
o 1つ以上の16ビットTLVエンコードされたメタデータがメタデータ長フィールドの後に続きます。 TLVタイプはメタデータIDを識別します。 IANAに登録されているForCESメタデータIDが使用されます。
All TLVs will be 32-bit-aligned. We recognize that using a 16-bit TLV restricts the metadata ID to 16 bits instead of a ForCES-defined component ID space of 32 bits if an Index-Length-Value (ILV) is used. However, at the time of publication, we believe this is sufficient to carry all the information we need; the TLV approach has been selected because it saves us 4 bytes per metadatum transferred as compared to the ILV approach.
すべてのTLVは32ビット境界で整列されます。 Index-Length-Value（ILV）が使用されている場合、16ビットTLVを使用すると、32ビットのForCES定義のコンポーネントIDスペースではなく、16ビットにメタデータIDが制限されることを認識しています。ただし、公開時点では、これで必要なすべての情報を十分に伝えることができます。 TLVアプローチが選択されたのは、ILVアプローチと比較して、転送されるメタデータごとに4バイトが節約されるためです。
o The original packet data payload is appended at the end of the metadata as shown.
o 元のパケットデータペイロードは、次のようにメタデータの最後に追加されます。
The Ethernet inter-FE LFB has two LFB input port groups and three LFB output ports as shown in Figure 7.
イーサネットインターFE LFBには、図7に示すように、2つのLFB入力ポートグループと3つのLFB出力ポートがあります。
The inter-FE LFB defines two components used in aiding processing described in Section 6.1.
Inter-FE LFBは、セクション6.1で説明されている処理を支援するために使用される2つのコンポーネントを定義します。
+-----------------+
Inter-FE LFB | |
Encapsulated | OUT2+--> Decapsulated Packet
-------------->|IngressInGroup | + metadata
Ethernet Frame | |
| |
raw Packet + | OUT1+--> Encapsulated Ethernet
-------------->|EgressInGroup | Frame
Metadata | |
| EXCEPTIONOUT +--> ExceptionID, packet
| | + metadata
+-----------------+
Figure 7: Inter-FE LFB
図7：Inter-FE LFB
The inter-FE LFB (instance) can be positioned at the egress of a source FE. Figure 5 illustrates an example source FE in the form of FE1. In such a case, an inter-FE LFB instance receives, via port group EgressInGroup, a raw packet and associated metadata from the preceding LFB instances. The input information is used to produce a selection of how to generate and encapsulate the new frame. The set of all selections is stored in the LFB component IFETable described further below. The processed encapsulated Ethernet frame will go out on OUT1 to a downstream LFB instance when processing succeeds or to the EXCEPTIONOUT port in the case of failure.
インターFE LFB（インスタンス）は、ソースFEの出口に配置できます。図5は、ソースFEの例をFE1の形式で示しています。このような場合、FE間LFBインスタンスは、ポートグループEgressInGroupを介して、前のLFBインスタンスから生のパケットと関連メタデータを受信します。入力情報は、新しいフレームを生成およびカプセル化する方法の選択を生成するために使用されます。すべての選択のセットは、以下でさらに説明するLFBコンポーネントIFETableに格納されます。処理されたカプセル化イーサネットフレームは、処理が成功した場合にOUT1からダウンストリームLFBインスタンスに送信され、失敗した場合はEXCEPTIONOUTポートに送信されます。
The inter-FE LFB (instance) can be positioned at the ingress of a receiving FE. Figure 5 illustrates an example destination FE in the form of FE1. In such a case, an inter-FE LFB receives, via an LFB port in the IngressInGroup, an encapsulated Ethernet frame. Successful processing of the packet will result in a raw packet with associated metadata IDs going downstream to an LFB connected on OUT2. On failure, the data is sent out EXCEPTIONOUT.
FE間LFB（インスタンス）は、受信FEの入口に配置できます。図5は、FE1の形式の宛先FEの例を示しています。このような場合、インターFE LFBは、IngressInGroupのLFBポートを介して、カプセル化されたイーサネットフレームを受信します。パケットの処理が成功すると、OUT2に接続されたLFBへのダウンストリームのメタデータIDが関連付けられた未加工のパケットになります。失敗すると、データはEXCEPTIONOUTに送信されます。
The egress inter-FE LFB receives packet data and any accompanying metadatum at an LFB port of the LFB instance's input port group labeled EgressInGroup.
出力FE間LFBは、LFGインスタンスのEgressInGroupというラベルの付いた入力ポートグループのLFBポートで、パケットデータと付随するメタデータを受信します。
The LFB implementation may use the incoming LFB port (within the LFB port group EgressInGroup) to map to a table index used to look up the IFETable table.
LFB実装は、着信LFBポート（LFBポートグループEgressInGroup内）を使用して、IFETableテーブルのルックアップに使用されるテーブルインデックスにマップすることができます。
If the lookup is successful, a matched table row that has the IFEInfo details is retrieved with the tuple (optional IFETYPE, optional StatId, Destination MAC address (DSTFE), Source MAC address (SRCFE), and optional metafilters). The metafilters lists define a whitelist of which metadatum are to be passed to the neighboring FE. The inter-FE LFB will perform the following actions using the resulting tuple:
ルックアップが成功すると、IFEInfoの詳細を持つ一致したテーブル行がタプル（オプションのIFETYPE、オプションのStatId、宛先MACアドレス（DSTFE）、ソースMACアドレス（SRCFE）、およびオプションのメタフィルター）で取得されます。メタフィルターリストは、メタデータが隣接するFEに渡されるホワイトリストを定義します。 FE間LFBは、結果のタプルを使用して次のアクションを実行します。
o Increment statistics for packet and byte count observed at the corresponding IFEStats entry.
o 対応するIFEStatsエントリで観察されたパケットおよびバイトカウントの統計を増分します。
o When the MetaFilterList is present, walk each received metadatum and apply it against the MetaFilterList. If no legitimate metadata is found that needs to be passed downstream, then the processing stops and the packet and metadata are sent out the EXCEPTIONOUT port with the exceptionID of EncapTableLookupFailed [RFC6956].
o MetaFilterListが存在する場合、受信した各メタデータを調べて、MetaFilterListに適用します。ダウンストリームに渡す必要がある正当なメタデータが見つからない場合、処理は停止し、パケットとメタデータは、ExceptionIDがEncapTableLookupFailed [RFC6956]のEXCEPTIONOUTポートから送信されます。
o Check that the additional overhead of the Ethernet header and encapsulated metadata will not exceed MTU. If it does, increment the error-packet-count statistics and send the packet and metadata out the EXCEPTIONOUT port with the exceptionID of FragRequired [RFC6956].
o イーサネットヘッダーとカプセル化されたメタデータの追加のオーバーヘッドがMTUを超えないことを確認します。存在する場合は、error-packet-count統計を増分し、パケットとメタデータを、FragRequired [RFC6956]のexceptionIDを使用してEXCEPTIONOUTポートから送信します。
o Create the Ethernet header.
o イーサネットヘッダーを作成します。
o Set the Destination MAC address of the Ethernet header with the value found in the DSTFE field.
o DSTFEフィールドにある値を使用して、イーサネットヘッダーの宛先MACアドレスを設定します。
o Set the Source MAC address of the Ethernet header with the value found in the SRCFE field.
o イーサネットヘッダーの送信元MACアドレスを、SRCFEフィールドにある値で設定します。
o If the optional IFETYPE is present, set the ethertype to the value found in IFETYPE. If IFETYPE is absent, then the standard inter-FE LFB ethertype ED3E (base 16) is used.
o オプションのIFETYPEが存在する場合は、ethertypeをIFETYPEにある値に設定します。 IFETYPEがない場合は、標準のインターFE LFBイーサタイプED3E（ベース16）が使用されます。
o Encapsulate each allowed metadatum in a TLV. Use the metaID as the "type" field in the TLV header. The TLV should be aligned to 32 bits. This means you may need to add a padding of zeroes at the end of the TLV to ensure alignment.
o 許可された各メタデータをTLVにカプセル化します。 metaIDをTLVヘッダーの「タイプ」フィールドとして使用します。 TLVは32ビットに揃える必要があります。つまり、アライメントを確実にするために、TLVの最後にゼロのパディングを追加する必要がある場合があります。
o Update the metadata length to the sum of each TLV's space plus 2 bytes (a 16-bit space for the Metadata length field).
o メタデータの長さを、各TLVのスペースと2バイトの合計（メタデータの長さフィールド用の16ビットのスペース）に更新します。
The resulting packet is sent to the next LFB instance connected to the OUT1 LFB-port, typically a port LFB.
結果のパケットは、OUT1 LFBポート（通常はポートLFB）に接続されている次のLFBインスタンスに送信されます。
In the case of a failed lookup, the original packet and associated metadata is sent out the EXCEPTIONOUT port with the exceptionID of EncapTableLookupFailed [RFC6956]. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above.
ルックアップに失敗した場合、元のパケットと関連するメタデータは、ExceptionIDがEncapTableLookupFailed [RFC6956]のEXCEPTIONOUTポートから送信されます。 EXCEPTIONOUT LFBポートは単なる抽象化であり、実装は上記のように実際にパケットをドロップする可能性があることに注意してください。
An ingressing inter-FE LFB packet is recognized by inspecting the ethertype, and optionally the destination and source MAC addresses. A matching packet is mapped to an LFB instance port in the IngressInGroup. The IFETable table row entry matching the LFB instance port may have optionally programmed metadata filters. In such a case, the ingress processing should use the metadata filters as a whitelist of what metadatum is to be allowed.
入力インターFE LFBパケットは、イーサタイプ、およびオプションで宛先および送信元MACアドレスを検査することによって認識されます。一致するパケットは、IngressInGroupのLFBインスタンスポートにマッピングされます。 LFBインスタンスポートに一致するIFETableテーブルの行エントリには、オプションでプログラムされたメタデータフィルターを含めることができます。このような場合、入力処理では、メタデータフィルターを、許可するメタデータのホワイトリストとして使用する必要があります。
o Increment statistics for packet and byte count observed.
o 観測されたパケット数とバイト数の統計の増分。
o Look at the metadata length field and walk the packet data, extracting the metadata values from the TLVs. For each metadatum extracted, in the presence of metadata filters, the metaID is compared against the relevant IFETable row metafilter list. If the metadatum is recognized and allowed by the filter, the corresponding implementation Metadatum field is set. If an unknown metadatum ID is encountered or if the metaID is not in the allowed filter list, then the implementation is expected to ignore it, increment the packet error statistic, and proceed processing other metadatum.
o メタデータの長さフィールドを見て、パケットデータを調べ、TLVからメタデータ値を抽出します。抽出されたメタデータごとに、メタデータフィルターが存在する場合、メタIDが関連するIFETable行のメタフィルターリストと比較されます。メタデータがフィルターによって認識および許可されると、対応する実装のメタデータフィールドが設定されます。不明なメタデータIDが検出された場合、または許可されたフィルターリストにメタIDが含まれていない場合、実装はそれを無視し、パケットエラー統計をインクリメントして、他のメタデータの処理を続行します。
o Upon completion of processing all the metadata, the inter-FE LFB instance resets the data point to the original payload (i.e., skips the IFE header information). At this point, the original packet that was passed to the egress inter-FE LFB at the source FE is reconstructed. This data is then passed along with the reconstructed metadata downstream to the next LFB instance in the graph.
o すべてのメタデータの処理が完了すると、FE間LFBインスタンスはデータポイントを元のペイロードにリセットします（つまり、IFEヘッダー情報をスキップします）。この時点で、ソースFEで出力FE間LFBに渡された元のパケットが再構築されます。このデータは、再構築されたメタデータとともに、グラフ内の次のLFBインスタンスに渡されます。
In the case of a processing failure of either ingress or egress positioning of the LFB, the packet and metadata are sent out the EXCEPTIONOUT LFB port with the appropriate error ID. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above.
LFBの入力または出力のポジショニングのいずれかの処理が失敗した場合、パケットとメタデータは適切なエラーIDとともにEXCEPTIONOUT LFBポートに送信されます。 EXCEPTIONOUT LFBポートは単なる抽象化であり、実装は上記のように実際にパケットをドロップする可能性があることに注意してください。
There are two LFB components accessed by the CE. The reader is asked to refer to the definitions in Figure 8.
CEによってアクセスされる2つのLFBコンポーネントがあります。読者は、図8の定義を参照するように求められます。
The first component, populated by the CE, is an array known as the "IFETable" table. The array rows are made up of IFEInfo structure. The IFEInfo structure constitutes the optional IFETYPE, the optionally present StatId, the Destination MAC address (DSTFE), the Source MAC address (SRCFE), and an optionally present array of allowed metaIDs (MetaFilterList).
CEによって作成される最初のコンポーネントは、「IFETable」テーブルと呼ばれる配列です。配列の行はIFEInfo構造で構成されています。 IFEInfo構造は、オプションのIFETYPE、オプションで存在するStatId、宛先MACアドレス（DSTFE）、ソースMACアドレス（SRCFE）、およびオプションで存在する許可されたメタIDの配列（MetaFilterList）を構成します。
The second component (ID 2), populated by the FE and read by the CE, is an indexed array known as the "IFEStats" table. Each IFEStats row carries statistics information in the structure bstats.
2番目のコンポーネント（ID 2）は、FEによって入力され、CEによって読み取られ、「IFEStats」テーブルと呼ばれるインデックス付き配列です。 IFEStatsの各行には、統計情報が構造体bstatsに含まれています。
A note about the StatId relationship between the IFETable table and the IFEStats table -- an implementation may choose to map between an IFETable row and IFEStats table row using the StatId entry in the matching IFETable row. In that case, the IFETable StatId must be present. An alternative implementation may map an IFETable row to an IFEStats table row at provisioning time. Yet another alternative implementation may choose not to use the IFETable row StatId and instead use the IFETable row index as the IFEStats index. For these reasons, the StatId component is optional.
IFETableテーブルとIFEStatsテーブルの間のStatId関係に関するメモ-実装では、一致するIFETable行のStatIdエントリを使用して、IFETable行とIFEStatsテーブル行の間のマッピングを選択できます。その場合、IFETable StatIdが存在する必要があります。別の実装では、プロビジョニング時にIFETable行をIFEStatsテーブル行にマップできます。さらに別の代替実装では、IFETable行StatIdを使用せず、代わりにIFETable行インデックスをIFEStatsインデックスとして使用する場合があります。これらの理由により、StatIdコンポーネントはオプションです。
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="IFE">
<frameDefs>
<frameDef>
<name>PacketAny</name>
<synopsis>Arbitrary Packet</synopsis>
</frameDef>
<frameDef>
<name>InterFEFrame</name>
<synopsis>
Ethernet frame with encapsulated IFE information
</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDefs>
<dataTypeDef>
<name>bstats</name>
<synopsis>Basic stats</synopsis>
<struct>
<component componentID="1">
<name>bytes</name>
<synopsis>The total number of bytes seen</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>packets</name>
<synopsis>The total number of packets seen</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>errors</name>
<synopsis>The total number of packets with errors</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IFEInfo</name>
<synopsis>Describing IFE table row Information</synopsis>
<struct>
<component componentID="1">
<name>IFETYPE</name>
<synopsis>
The ethertype to be used for outgoing IFE frame
</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>StatId</name>
<synopsis>
The Index into the stats table
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>DSTFE</name>
<synopsis>
The destination MAC address of the destination FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="4">
<name>SRCFE</name>
<synopsis>
The source MAC address used for the source FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="5">
<name>MetaFilterList</name>
<synopsis>
The allowed metadata filter table
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="18">
<name>IFE</name>
<synopsis>
This LFB describes IFE connectivity parameterization
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPorts>
<inputPort group="true">
<name>EgressInGroup</name>
<synopsis>
The input port group of the egress side.
It expects any type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>PacketAny</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort group="true">
<name>IngressInGroup</name>
<synopsis>
The input port group of the ingress side.
It expects an interFE-encapsulated Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>InterFEFrame</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPorts>
<outputPort>
<name>OUT1</name>
<synopsis>
The output port of the egress side
</synopsis>
<product>
<frameProduced>
<ref>InterFEFrame</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>OUT2</name>
<synopsis>
The output port of the Ingress side
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>EXCEPTIONOUT</name>
<synopsis>
The exception handling path
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<コンポーネント>
<component componentID="1" access="read-write">
<name>IFETable</name>
<synopsis>
The table of all inter-FE relations
</synopsis>
<array type="variable-size">
<typeRef>IFEInfo</typeRef>
</array>
</component>
<component componentID="2" access="read-only">
<name>IFEStats</name>
<synopsis>
The stats corresponding to the IFETable table
</synopsis>
<typeRef>bstats</typeRef>
</component>
</components>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Figure 8: Inter-FE LFB XML
図8：Inter-FE LFB XML
IANA has registered the following LFB class name in the "Logical Functional Block (LFB) Class Names and Class Identifiers" subregistry of the "Forwarding and Control Element Separation (ForCES)" registry <https://www.iana.org/assignments/forces>.
IANAは、「Forwarding and Control Element Separation（ForCES）」レジストリの「Logical Functional Block（LFB）Class Names and Class Identifiers」サブレジストリに次のLFBクラス名を登録しました<https://www.iana.org/assignments/力>。
+------------+--------+---------+-----------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+--------+---------+-----------------------+-----------+
| 18 | IFE | 1.0 | An IFE LFB to | This |
| | | | standardize inter-FE | document |
| | | | LFB for ForCES | |
| | | | Network Elements | |
+------------+--------+---------+-----------------------+-----------+
Logical Functional Block (LFB) Class Names and Class Identifiers
論理機能ブロック（LFB）のクラス名とクラス識別子
This memo includes a request for a new Ethernet protocol type as described in Section 5.2.
このメモには、セクション5.2で説明されている新しいイーサネットプロトコルタイプのリクエストが含まれています。
The FEs involved in the inter-FE LFB belong to the same NE and are within the scope of a single administrative Ethernet LAN private network. While trust of policy in the control and its treatment in the datapath exists already, an inter-FE LFB implementation SHOULD support security services provided by Media Access Control Security (MACsec) [ieee8021ae]. MACsec is not currently sufficiently widely deployed in traditional packet processing hardware although it is present in newer versions of the Linux kernel (which will be widely deployed) [linux-macsec]. Over time, we expect that most FEs will be able to support MACsec.
FE間LFBに含まれるFEは同じNEに属し、単一の管理イーサネットLANプライベートネットワークのスコープ内にあります。コントロールのポリシーの信頼とデータパスでのその処理はすでに存在しますが、FE間LFB実装は、メディアアクセスコントロールセキュリティ（MACsec）[ieee8021ae]によって提供されるセキュリティサービスをサポートする必要があります（SHOULD）。 MACsecは、Linuxカーネルの新しいバージョン（広く展開される予定）[linux-macsec]に存在していますが、現在のところ、従来のパケット処理ハードウェアには十分に広く展開されていません。今後、ほとんどのFEがMACsecをサポートできるようになると予想しています。
MACsec provides security services such as a message authentication service and an optional confidentiality service. The services can be configured manually or automatically using the MACsec Key Agreement (MKA) over the IEEE 802.1x [ieee8021x] Extensible Authentication Protocol (EAP) framework. It is expected that FE implementations are going to start with shared keys configured from the control plane but progress to automated key management.
MACsecは、メッセージ認証サービスやオプションの機密性サービスなどのセキュリティサービスを提供します。サービスは、IEEE 802.1x [ieee8021x]拡張認証プロトコル（EAP）フレームワークを介してMACsec Key Agreement（MKA）を使用して手動または自動で構成できます。 FEの実装は、コントロールプレーンから構成された共有キーから始まり、自動キー管理に進むことが予想されます。
The following are the MACsec security mechanisms that need to be in place for the inter-FE LFB:
以下は、インターFE LFBに配置する必要があるMACsecセキュリティメカニズムです。
o Security mechanisms are NE-wide for all FEs. Once the security is turned on, depending upon the chosen security level (e.g., Authentication, Confidentiality), it will be in effect for the inter-FE LFB for the entire duration of the session.
o すべてのFEのセキュリティメカニズムはNE全体です。セキュリティがオンになると、選択したセキュリティレベル（認証、機密性など）に応じて、セッションの全期間中、インターFE LFBに対して有効になります。
o An operator SHOULD configure the same security policies for all participating FEs in the NE cluster. This will ensure uniform operations and avoid unnecessary complexity in policy configuration. In other words, the Security Association Keys (SAKs) should be pre-shared. When using MKA, FEs must identify themselves with a shared Connectivity Association Key (CAK) and Connectivity Association Key Name (CKN). EAP-TLS SHOULD be used as the EAP method.
o オペレーターは、NEクラスターに参加しているすべてのFEに同じセキュリティポリシーを設定する必要があります（SHOULD）。これにより、操作が均一になり、ポリシー構成の不要な複雑化が回避されます。つまり、セキュリティアソシエーションキー（SAK）は事前共有する必要があります。 MKAを使用する場合、FEは共有接続アソシエーションキー（CAK）と接続アソシエーションキー名（CKN）で自分自身を識別する必要があります。 EAP-TLSは、EAPメソッドとして使用する必要があります（SHOULD）。
o An operator SHOULD configure the strict validation mode, i.e., all non-protected, invalid, or non-verifiable frames MUST be dropped.
o オペレーターは厳格な検証モードを設定する必要があります。つまり、保護されていない、無効な、または検証不可能なすべてのフレームをドロップする必要があります。
It should be noted that given the above choices, if an FE is compromised, an entity running on the FE would be able to fake inter-FE or modify its content, causing bad outcomes.
上記の選択を考えると、FEが侵害された場合、FE上で実行されているエンティティは、FE間を偽造したり、そのコンテンツを変更したりして、悪い結果を引き起こす可能性があることに注意してください。
[ieee8021ae] IEEE, "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.
[ieee8021ae] IEEE、「IEEE Standard for Local and Metropolitan Area Network Media Access Control（MAC）Security」、IEEE 802.1AE-2006、DOI 10.1109 / IEEESTD.2006.245590、<http://ieeexplore.ieee.org/document/1678345 />。
[ieee8021x] IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control.", IEEE 802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.
[ieee8021x] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control。」、IEEE 802.1X-2010、DOI 10.1109 / IEEESTD.2010.5409813、<http://ieeexplore.ieee.org/document/ 5409813 />。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810]ドリア、A。、編、ハディサリム、J。、編、ハース、R。、編、コスラビ、H。、編、王、W。、編、ドン、L。、ゴパル、R。、およびJ. Halpern、「Forwarding and Control Element Separation（ForCES）Protocol Specification」、RFC 5810、DOI 10.17487 / RFC5810、2010年3月、<http://www.rfc-editor.org/info/rfc5810> 。
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, DOI 10.17487/RFC5811, March 2010, <http://www.rfc-editor.org/info/rfc5811>.
[RFC5811] Hadi Salim、J。およびK. Ogawa、「Forwarding and Control Element Separation（ForCES）ProtocolのSCTPベースのトランスポートマッピングレイヤー（TML）」、RFC 5811、DOI 10.17487 / RFC5811、2010年3月、<http： //www.rfc-editor.org/info/rfc5811>。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, DOI 10.17487/RFC5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、DOI 10.17487 / RFC5812、March 2010、<http://www.rfc-editor.org / info / rfc5812>。
[RFC7391] Hadi Salim, J., "Forwarding and Control Element Separation (ForCES) Protocol Extensions", RFC 7391, DOI 10.17487/RFC7391, October 2014, <http://www.rfc-editor.org/info/rfc7391>.
[RFC7391] Hadi Salim、J。、「Forwarding and Control Element Separation（ForCES）Protocol Extensions」、RFC 7391、DOI 10.17487 / RFC7391、2014年10月、<http://www.rfc-editor.org/info/rfc7391> 。
[RFC7408] Haleplidis, E., "Forwarding and Control Element Separation (ForCES) Model Extension", RFC 7408, DOI 10.17487/RFC7408, November 2014, <http://www.rfc-editor.org/info/rfc7408>.
[RFC7408] Haleplidis、E。、「Forwarding and Control Element Separation（ForCES）Model Extension」、RFC 7408、DOI 10.17487 / RFC7408、2014年11月、<http://www.rfc-editor.org/info/rfc7408>。
[brcm-higig] Broadcom, "HiGig", <http://www.broadcom.com/products/ ethernet-communication-and-switching/switching/bcm56720>.
[brcm-higig] Broadcom、「HiGig」、<http://www.broadcom.com/products/ ethernet-communication-and-switching / switching / bcm56720>。
[circuit-b] Fairhurst, G., "Network Transport Circuit Breakers", Work in Progress, draft-ietf-tsvwg-circuit-breaker-15, April 2016.
[circuit-b] Fairhurst、G。、「Network Transport Circuit Breakers」、Work in Progress、draft-ietf-tsvwg-circuit-breaker-15、2016年4月。
[linux-macsec] Dubroca, S., "MACsec: Encryption for the wired LAN", Netdev 11, Feb 2016.
[linux-macsec] Dubroca、S。、「MACsec：Encryption for the有線LAN」、Netdev 11、2016年2月。
[linux-tc] Hadi Salim, J., "Linux Traffic Control Classifier-Action Subsystem Architecture", Netdev 01, Feb 2015.
[linux-tc] Hadi Salim、J。、「Linux Traffic Control Classifier-Action Subsystem Architecture」、Netdev 01、2015年2月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、DOI 10.17487 / RFC3746、2004年4月、<http：/ /www.rfc-editor.org/info/rfc3746>。
[RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", RFC 6956, DOI 10.17487/RFC6956, June 2013, <http://www.rfc-editor.org/info/rfc6956>.
[RFC6956] Wang、W.、Haleplidis、E.、Ogawa、K.、Li、C。、およびJ. Halpern、「Forwarding and Control Element Separation（ForCES）Logical Function Block（LFB）Library」、RFC 6956、DOI 10.17487 / RFC6956、2013年6月、<http://www.rfc-editor.org/info/rfc6956>。
[tc-ife] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux Traffic Control Classifier-Action Subsystem", Netdev 01, Feb 2015.
[tc-ife] Hadi Salim、J。およびD. Joachimpillai、「Distributioning Linux Traffic Control Classifier-Action Subsystem」、Netdev 01、2015年2月。
[UDP-GUIDE] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", Work in Progress, draft-ietf-tsvwg-rfc5405bis-19, October 2016.
[UDP-GUIDE] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP Usage Guidelines」、Work in Progress、draft-ietf-tsvwg-rfc5405bis-19、2016年10月。
Acknowledgements
謝辞
The authors would like to thank Joel Halpern and Dave Hood for the stimulating discussions. Evangelos Haleplidis shepherded and contributed to improving this document. Alia Atlas was the AD sponsor of this document and did a tremendous job of critiquing it. The authors are grateful to Joel Halpern and Sue Hares in their roles as the Routing Area reviewers for shaping the content of this document. David Black put in a lot of effort to make sure the congestion-control considerations are sane. Russ Housley did the Gen-ART review, Joe Touch did the TSV area review, and Shucheng LIU (Will) did the OPS review. Suresh Krishnan helped us provide clarity during the IESG review. The authors are appreciative of the efforts Stephen Farrell put in to fixing the security section.
刺激的な議論をしてくれたJoel HalpernとDave Hoodに感謝します。 Evangelos Haleplidisは、この文書の作成と改善に貢献しました。 Alia Atlasはこの文書のADスポンサーであり、それを批評するという途方もない仕事をしました。著者は、このドキュメントのコンテンツを形成するためのルーティングエリアレビューアとしての役割を果たしたJoel HalpernとSue Haresに感謝します。 David Blackは、輻輳制御の考慮事項が適切であることを確認するために多くの努力をしました。 Russ HousleyがGen-ARTレビューを行い、Joe TouchがTSVエリアレビューを行い、Shucheng LIU（Will）がOPSレビューを行いました。 Suresh Krishnanは、IESGレビューで明快さを提供するのに役立ちました。著者は、Stephen Farrellがセキュリティセクションの修正に費やした努力に感謝しています。
Authors' Addresses
著者のアドレス
Damascane M. Joachimpillai Verizon 60 Sylvan Rd Waltham, MA 02451 United States of America
Damascane M. Joachimpillai Verizon 60 Sylvan Rd Waltham、MA 02451アメリカ合衆国
Email: damascene.joachimpillai@verizon.com
Jamal Hadi Salim Mojatatu Networks Suite 200, 15 Fitzgerald Rd. Ottawa, Ontario K2H 9G1 Canada
Jamal Hadi Salim Mojatatu Networks Suite 200、15 Fitzgerald Rd。オンタリオ州オタワK2H 9G1カナダ
Email: hadi@mojatatu.com