[要約] RFC 8459は、階層的なサービス機能チェイニング（hSFC）のためのプロトコル仕様です。hSFCは、ネットワークサービスの効率的な提供と管理を目的としています。
Internet Engineering Task Force (IETF) D. Dolson
Request for Comments: 8459 Sandvine
Category: Experimental S. Homma
ISSN: 2070-1721 NTT
D. Lopez
Telefonica I+D
M. Boucadair
Orange
September 2018
Hierarchical Service Function Chaining (hSFC)
階層型サービス関数チェーン（hSFC）
Abstract
概要
Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.
階層型サービス機能チェーン（hSFC）は、組織が大規模ネットワークを複数の管理ドメインに分解できるようにするネットワークアーキテクチャです。
The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.
hSFCの目標は、大規模ネットワークを設計しやすく、制御しやすくし、大規模ネットワークオペレーター内の独立した機能グループをサポートすることです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 https://www.rfc-editor.org/info/rfc8459.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8459で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 6
3.1. Upper Level . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 8
4. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 10
4.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 10
4.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 11
4.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 12
4.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 13
4.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 13
4.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 14
4.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 16
4.3. Decrementing Service Index . . . . . . . . . . . . . . . 16
4.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 16
5. Subdomain Classifier . . . . . . . . . . . . . . . . . . . . 17
6. Control Plane Elements . . . . . . . . . . . . . . . . . . . 18
7. Extension for Adapting to NSH-Unaware Service Functions . . . 18
7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Requirements for an IBN . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Hierarchical Service Function Chaining . 24
A.1. Reducing the Number of Service Function Paths . . . . . . 24
A.2. Managing a Distributed DC Network . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Service Function Chaining (SFC) is a technique for prescribing differentiated traffic-forwarding policies within an SFC-enabled domain. The SFC architecture is described in detail in [RFC7665] and is not repeated here.
Service Function Chaining（SFC）は、SFC対応ドメイン内で差別化されたトラフィック転送ポリシーを規定するための手法です。 SFCアーキテクチャは[RFC7665]で詳細に説明されており、ここでは繰り返されません。
This document focuses on the difficult problem of implementing SFC across a large, geographically dispersed network, potentially comprised of millions of hosts and thousands of network-forwarding elements and which may involve multiple operational teams (with varying functional responsibilities). We recognize that some stateful Service Functions (SFs) require bidirectional traffic for transport-layer sessions (e.g., NATs, firewalls). We assume that some Service Function Paths (SFPs) need to be selected on the basis of transport-layer coordinate (typically, the 5-tuple of source IP address, source port number, destination IP address, destination port number, and transport protocol) stickiness to specific stateful SF instances.
このドキュメントでは、地理的に分散した大規模なネットワーク全体にSFCを実装するという困難な問題に焦点を当てています。数百万のホストと数千のネットワーク転送要素で構成される可能性があり、複数の運用チーム（さまざまな機能的責任を持つ）が関与する可能性があります。一部のステートフルサービス機能（SF）では、トランスポート層セッション（NAT、ファイアウォールなど）に双方向トラフィックが必要であることを認識しています。一部のサービス機能パス（SFP）は、トランスポート層の座標（通常、ソースIPアドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、およびトランスポートプロトコルの5タプル）に基づいて選択する必要があると想定します特定のステートフルSFインスタンスへの粘着性。
Difficult problems are often made easier by decomposing them in a hierarchical (nested) manner. So, instead of considering a single SFC control plane that can manage (create, withdraw, supervise, etc.) complete SFPs from one end of the network to the other, we decompose the network into smaller domains operated by as many SFC control plane components (under the same administrative entity). Coordination between such components is further discussed in this document.
多くの場合、困難な問題は、階層的な（入れ子の）方法で分解することによって簡単になります。したがって、ネットワークの一方の端からもう一方の端まで完全なSFPを管理（作成、撤回、監視など）できる単一のSFCコントロールプレーンを検討する代わりに、ネットワークをより多くのSFCコントロールプレーンコンポーネントによって運用されるより小さなドメインに分解します。 （同じ管理エンティティの下）。このようなコンポーネント間の調整については、このドキュメントで詳しく説明します。
Each subdomain may support a subset of the network applications or a subset of the users. Decomposing a network should be done with care to ease monitoring and troubleshooting of the network and services as a whole. The criteria for decomposing a domain into multiple SFC-enabled subdomains are beyond the scope of this document. These criteria are deployment specific.
各サブドメインは、ネットワークアプリケーションのサブセットまたはユーザーのサブセットをサポートできます。ネットワークの分解は、ネットワークとサービス全体の監視とトラブルシューティングを容易にするために注意して行う必要があります。ドメインを複数のSFC対応サブドメインに分解する基準は、このドキュメントの範囲外です。これらの基準はデプロイメント固有です。
An example of simplifying a network by using multiple SFC-enabled domains is further discussed in [USE-CASES].
複数のSFC対応ドメインを使用してネットワークを簡略化する例は、[USE-CASES]でさらに説明されています。
We assume the SFC-aware nodes use the Network Service Header (NSH) [RFC8300] or a similar labeling mechanism. Examples are described in Appendix A.
SFC対応ノードは、ネットワークサービスヘッダー（NSH）[RFC8300]または同様のラベル付けメカニズムを使用すると想定しています。例は付録Aで説明されています。
The SFC-enabled domains discussed in this document are assumed to be under the control of a single organization (an operator, typically), such that there is a strong trust relationship between the domains. The intention of creating multiple domains is to improve the ability to operate a network. It is outside of the scope of this document to consider domains operated by different organizations or dwell on interoperator considerations.
このドキュメントで説明するSFC対応ドメインは、ドメイン間に強い信頼関係があるように、単一の組織（通常はオペレーター）の制御下にあると想定されています。複数のドメインを作成する目的は、ネットワークを操作する機能を改善することです。さまざまな組織によって運営されているドメインを検討したり、相互運用者の考慮事項を検討したりすることは、このドキュメントの範囲外です。
We introduce the concept of an Internal Boundary Node (IBN) that acts as a gateway between the levels of the hierarchy. We also discuss options for realizing this function.
階層のレベル間のゲートウェイとして機能する内部境界ノード（IBN）の概念を紹介します。この機能を実現するためのオプションについても説明します。
This document defines an architecture that aims to solve complications that may be encountered when deploying SFC in large networks. A single network is therefore decomposed into multiple subdomains, each treated as an SFC-enabled domain. Levels of hierarchy are defined, together with SFC operations that are specific to each level. In order to ensure consistent SFC operations when multiple subdomains are involved, this document identifies and analyzes various options for IBNs to glue the layers together (Section 4.1).
このドキュメントでは、SFCを大規模なネットワークに展開するときに発生する可能性がある複雑さを解決することを目的としたアーキテクチャを定義します。したがって、単一のネットワークは複数のサブドメインに分解され、それぞれがSFC対応ドメインとして扱われます。階層のレベルは、各レベルに固有のSFC操作とともに定義されます。複数のサブドメインが関係する場合に一貫したSFC動作を保証するために、このドキュメントでは、レイヤーを結合するためのIBNのさまざまなオプションを識別および分析します（セクション4.1）。
Because it does not make any assumptions about (1) how subdomains are defined, (2) whether one or multiple IBNs are enabled per subdomain, (3) whether the same IBN is solicited at both the ingress and egress of a subdomain for the same flow, (4) the nature of the internal paths to reach SFs within a subdomain, or (5) the lack of deployment feedback, this document does not call for a recommended option to glue the SFC layers together.
（1）サブドメインの定義方法、（2）サブドメインごとに1つまたは複数のIBNが有効になっているかどうか、（3）同じIBNが同じサブドメインの入力と出力の両方で送信請求されているかどうかについては想定していません。フロー、（4）サブドメイン内のSFに到達するための内部パスの性質、または（5）デプロイメントのフィードバックがない場合、このドキュメントでは、SFCレイヤーを接着するための推奨オプションは必要ありません。
Further experiments are required to test and evaluate the different options. A recommendation for hSFC might be documented in a future specification when the results of implementation and deployment of the aforementioned options are available.
さまざまなオプションをテストおよび評価するには、さらに実験が必要です。 hSFCの推奨事項は、前述のオプションの実装と展開の結果が利用可能になったときに、将来の仕様に文書化される可能性があります。
It is not expected that all the options discussed in this document will be implemented and deployed. The lack of an implementation might be seen as a signal to recommend against a given option.
このドキュメントで説明されているすべてのオプションが実装および展開されることは想定されていません。実装の欠如は、特定のオプションに対して推奨するシグナルと見なされる場合があります。
This document makes use of the terms defined in Section 1.4 of [RFC7665] and Section 1.3 of [RFC8300].
このドキュメントでは、[RFC7665]のセクション1.4と[RFC8300]のセクション1.3で定義されている用語を使用します。
The following terms are defined:
次の用語が定義されています。
o Upper-level domain: the entire network domain to be managed.
o 上位ドメイン：管理対象のネットワークドメイン全体。
o Lower-level domain: a portion of the network (called a subdomain).
o 下位ドメイン：ネットワークの一部（サブドメインと呼ばれる）。
o Internal Boundary Node (IBN): is responsible for bridging packets between upper and lower levels of SFC-enabled domains.
o 内部境界ノード（IBN）：SFCが有効なドメインの上位レベルと下位レベルの間でパケットをブリッジします。
A hierarchy has multiple levels: the topmost level encompasses the entire network domain to be managed, and lower levels encompass portions of the network. These levels are discussed in the following subsections.
階層には複数のレベルがあります。最上位レベルには管理対象のネットワークドメイン全体が含まれ、下位レベルにはネットワークの一部が含まれます。これらのレベルについては、次のサブセクションで説明します。
Considering the example depicted in Figure 1, a top-level network domain includes SFC data plane components distributed over a wide area, including:
図1に示す例を考えると、トップレベルのネットワークドメインには、次のような広域に分散されたSFCデータプレーンコンポーネントが含まれています。
o Classifiers (CFs)
o 分類子（CF）
o Service Function Forwarders (SFFs)
o サービス機能フォワーダー（SFF）
o Subdomains
o サブドメイン
+------------+
|Subdomain#1 |
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +----+
+----+ / / | \--|CF#4|
--->|CF#1|--/---->' | \ +----+
+----+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+----+ \ | / / +----+
|CF#2|---\ | / /---|CF#3|
+----+ '---- SFF2 ------' +----+
|
+----+-------+
|Subdomain#2 |
| in DC2 |
+------------+
Legend: SC#1: Service Chain 1 DC: Data Center
凡例：SC＃1：サービスチェーン1 DC：データセンター
Figure 1: Network-Wide View of Upper Level of Hierarchy
図1：階層の上位レベルのネットワーク全体のビュー
One path is shown from edge classifier (CF#1) to SFF1 to Subdomain#1 (residing in Data Center 1) to SFF1 to SFF2 (residing in Data Center 2) to Subdomain#2 to SFF2 to network egress.
1つのパスは、エッジ分類子（CF＃1）からSFF1、サブドメイン＃1（データセンター1に存在）、SFF1からSFF2（データセンター2に存在）、サブドメイン＃2からSFF2、ネットワーク出口の順に示されています。
For the sake of clarity, components of the underlay network are not shown; an underlay network is assumed to provide connectivity between SFC data plane components.
明確にするために、アンダーレイネットワークのコンポーネントは示していません。アンダーレイネットワークは、SFCデータプレーンコンポーネント間の接続を提供すると想定されています。
Top-level SFPs carry packets from classifiers through a set of SFFs and subdomains, with the operations within subdomains being opaque to the upper levels.
最上位のSFPは、分類子からのパケットを一連のSFFとサブドメインを介して伝送し、サブドメイン内の操作は上位レベルに対して不透明です。
We expect the system to include a top-level control plane having responsibility for configuring forwarding policies and traffic-classification rules.
システムには、転送ポリシーとトラフィック分類ルールの構成を担当するトップレベルのコントロールプレーンが含まれていると想定しています。
The top-level Service Chaining control plane manages end-to-end service chains and associated service function paths from network edge points to subdomains. It also configures top-level classifiers at a coarse level (e.g., based on source or destination host) to forward traffic along paths that will transit across appropriate subdomains.
トップレベルのサービスチェーンコントロールプレーンは、エンドツーエンドのサービスチェーンと、ネットワークエッジポイントからサブドメインへの関連するサービス機能パスを管理します。また、適切なサブドメイン間を通過するパスに沿ってトラフィックを転送するために、（送信元または宛先ホストに基づいて）大まかなレベルでトップレベルの分類子を構成します。
Figure 1 shows one possible service chain passing from the edge through two subdomains to network egress. The top-level control plane does not configure traffic-classification rules or forwarding policies within the subdomains.
図1は、エッジから2つのサブドメインを経由してネットワーク出力に至る1つの可能なサービスチェーンを示しています。トップレベルのコントロールプレーンは、サブドメイン内のトラフィック分類ルールまたは転送ポリシーを設定しません。
At this network-wide level, the number of SFPs required is a linear function of the number of ways in which a packet is required to traverse different subdomains and egress the network. Note that the various paths that may be followed within a subdomain are not represented by distinct network-wide SFPs; specific policies at the ingress nodes of each subdomain bind flows to subdomain paths.
このネットワーク全体のレベルでは、必要なSFPの数は、さまざまなサブドメインを通過してネットワークから出力するためにパケットが必要とされる方法の数の線形関数です。サブドメイン内をたどることができるさまざまなパスは、ネットワーク全体の異なるSFPでは表されないことに注意してください。各サブドメインの入力ノードの特定のポリシーは、フローをサブドメインパスにバインドします。
Packets are classified at the edge of the network to select the paths by which subdomains are to be traversed. At the ingress of each subdomain, packets are reclassified to paths directing them to the required SFs of the subdomain. At the egress of each subdomain, packets are returned to the top-level paths. Contrast this with an approach requiring the top-level classifier to select paths to specify all of the SFs in each subdomain.
パケットはネットワークのエッジで分類され、サブドメインを通過するパスを選択します。各サブドメインの入口で、パケットは、サブドメインの必要なSFにそれらを導くパスに再分類されます。各サブドメインの出口で、パケットはトップレベルのパスに返されます。これを、トップレベルの分類子がパスを選択して各サブドメインのすべてのSFを指定する必要があるアプローチとは対照的です。
It should be assumed that some SFs require bidirectional symmetry of paths (see more in Section 5). Therefore, the classifiers at the top level must be configured with policies ensuring outgoing packets take the reverse path of incoming packets through subdomains.
一部のSFではパスの双方向の対称性が必要であると想定する必要があります（セクション5を参照）。したがって、最上位レベルの分類子には、発信パケットがサブドメインを介して着信パケットの逆のパスを通るようにするポリシーを設定する必要があります。
Each of the subdomains in Figure 1 is an SFC-enabled domain.
図1の各サブドメインは、SFC対応のドメインです。
Figure 2 shows a subdomain interfaced with an upper-level domain by means of an Internal Boundary Node (IBN). An IBN acts as an SFC-aware SF in the upper-level domain and as a classifier in the lower-level domain. As such, data packets entering the subdomain are already SFC encapsulated. Also, it is the purpose of the IBN to apply classification rules and direct the packets to the selected local SFPs terminating at an egress IBN. Finally, the egress IBN restores packets to the original SFC shim and hands them off to SFFs.
図2は、内部境界ノード（IBN）を使用して上位レベルドメインとインターフェイスするサブドメインを示しています。 IBNは、上位レベルのドメインではSFC対応のSFとして機能し、下位レベルのドメインでは分類子として機能します。そのため、サブドメインに入るデータパケットはすでにSFCカプセル化されています。また、分類ルールを適用し、出力IBNで終端する選択されたローカルSFPにパケットを転送することがIBNの目的です。最後に、出力IBNはパケットを元のSFCシムに復元し、SFFに渡します。
Each subdomain intersects a subset of the total paths that are possible in the upper-level domain. An IBN is concerned with upper-level paths, but only those traversing its subdomain.
各サブドメインは、上位レベルドメインで可能な全パスのサブセットと交差します。 IBNは上位レベルのパスに関係しますが、そのサブドメインを通過するものだけです。
Each subdomain is likely to have a control plane that can operate independently of the top-level control plane, managing classification, forwarding paths, etc., within the level of the subdomain, with the details being opaque to the upper-level control elements. Section 4 provides more details about the behavior of an IBN.
各サブドメインには、トップレベルのコントロールプレーンから独立して動作し、サブドメインのレベル内で分類、転送パスなどを管理できるコントロールプレーンがあり、詳細は上位レベルのコントロールエレメントに対して不透明です。セクション4では、IBNの動作について詳しく説明します。
The subdomain control plane configures the classification rules in the IBN, where SFC encapsulation of the top-level domain is converted to/from SFC encapsulation of the lower-level domain. The subdomain control plane also configures the forwarding rules in the SFFs of the subdomain.
サブドメインコントロールプレーンは、IBNの分類規則を構成します。この場合、最上位ドメインのSFCカプセル化は、下位レベルドメインのSFCカプセル化との間で変換されます。サブドメインコントロールプレーンは、サブドメインのSFFに転送ルールも設定します。
+----+ +-----+ +----------------------+ +-----+
| | | SFF | | IBN 1 (in DC 1) | | SFF |
| |SC#1| | | +----------------+ | | |
->| |===============>| SFF |================>
| | +-----+ | +----------------+ | +-----+
| CF | | | ^ |
| | | v | |
| | |+--------------------+| Upper domain
| | ||CF, fwd/rev mapping ||
| | * * * * *|| and "glue" || * * * * *
| | * |+--------------------+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
Legend:
*** Subdomain boundary
=== upper-level chain
--- lower-level chain
Figure 2: Example of a Subdomain within an Upper-Level Domain
図2：上位レベルドメイン内のサブドメインの例
If desired, the pattern can be applied recursively. For example, SF#1.1 in Figure 2 could be a subdomain of the subdomain.
必要に応じて、パターンを再帰的に適用できます。たとえば、図2のSF＃1.1は、サブドメインのサブドメインになる可能性があります。
As mentioned in the previous section, a network element termed an "Internal Boundary Node" (or IBN) is responsible for bridging packets between upper and lower layers of SFC-enabled domains. It behaves as an SF to the upper level (Section 3.1) and looks like a classifier and end of chain to the lower level (Section 3.2).
前のセクションで述べたように、「内部境界ノード」（またはIBN）と呼ばれるネットワーク要素は、SFC対応ドメインの上位層と下位層の間でパケットをブリッジする役割を果たします。上位レベル（セクション3.1）へのSFとして動作し、分類子および下位レベル（セクション3.2）へのチェーンの終わりのように見えます。
To achieve the benefits of hierarchy, the IBN should be applying fine-grained traffic-classification rules at a lower level than the traffic passed to it. This means that the number of SFPs within the lower level is greater than the number of SFPs arriving to the IBN.
階層の利点を実現するには、IBNは、渡されたトラフィックよりも低いレベルで、きめ細かなトラフィック分類ルールを適用する必要があります。これは、下位レベル内のSFPの数がIBNに到着するSFPの数より多いことを意味します。
The IBN is also the termination of lower-level SFPs. This is because the packets exiting lower-level SFPs must be returned to the upper-level SFPs and forwarded to the next hop in the upper-level domain.
IBNは、下位レベルのSFPの終端でもあります。これは、下位レベルのSFPを出たパケットを上位レベルのSFPに戻して、上位レベルドメインのネクストホップに転送する必要があるためです。
When different metadata schemes are used at different levels, the IBN has further responsibilities: when packets enter the subdomain, the IBN translates upper-level metadata into lower-level metadata; and when packets leave the subdomain at the termination of lower-level SFPs, the IBN translates lower-level metadata into upper-level metadata.
異なるメタデータスキームが異なるレベルで使用される場合、IBNにはさらに責任があります。パケットがサブドメインに入ると、IBNは上位レベルのメタデータを下位レベルのメタデータに変換します。パケットが下位レベルのSFPの終端でサブドメインを離れると、IBNは下位レベルのメタデータを上位レベルのメタデータに変換します。
Appropriately configuring IBNs is key to ensuring the consistency of the overall SFC operation within a given domain that enables hSFC. Classification rules (or lack thereof) in the IBN classifier can, of course, impact upper levels.
IBNを適切に構成することは、hSFCを有効にする特定のドメイン内のSFC動作全体の一貫性を確保するための鍵です。もちろん、IBN分類子の分類ルール（またはその欠如）は、上位レベルに影響を与える可能性があります。
The lower-level domain may be provisioned with valid upper-level paths or allow any upper-level paths.
下位ドメインには、有効な上位レベルのパスをプロビジョニングするか、上位レベルのパスを許可することができます。
When packets enter the subdomain, the Service Path Identifier (SPI) and Service Index (SI) are re-marked according to the path selected by the (subdomain) classifier.
パケットがサブドメインに入ると、サービスパス識別子（SPI）とサービスインデックス（SI）は、（サブドメイン）分類子によって選択されたパスに従って再マーキングされます。
At the termination of an SFP in the subdomain, packets can be restored to an original upper-level SFP by implementing one of these methods:
サブドメイン内のSFPの終端で、次のいずれかの方法を実装することにより、パケットを元の上位レベルのSFPに復元できます。
1. Saving the SPI and SI in transport-layer flow state (Section 4.1.1).
1. SPIおよびSIをトランスポート層フロー状態で保存する（セクション4.1.1）。
2. Pushing the SPI and SI into a metadata header (Section 4.1.2).
2. SPIとSIをメタデータヘッダーにプッシュする（セクション4.1.2）。
3. Using unique lower-level paths per upper-level path coordinates (Section 4.1.3).
3. 上位レベルのパス座標ごとに一意の下位レベルパスを使用する（セクション4.1.3）。
4. Nesting NSH headers, encapsulating the upper-level NSH headers within the lower-level NSH headers (Section 4.1.4).
4. NSHヘッダーをネストし、上位NSHヘッダーを下位NSHヘッダー内にカプセル化します（セクション4.1.4）。
5. Saving the upper level with a flow identifier (ID) and placing an hSFC Flow ID into a metadata header (Section 4.1.5).
5. 上位レベルをフロー識別子（ID）で保存し、hSFCフローIDをメタデータヘッダーに配置します（セクション4.1.5）。
An IBN can be flow aware, returning packets to the correct upper-level SFP on the basis, for example, of the transport-layer coordinates (typically, a 5-tuple) of packets exiting the lower-level SFPs.
IBNはフローに対応しており、たとえば、下位レベルのSFPから出て行くパケットのトランスポート層座標（通常は5タプル）に基づいて、正しい上位レベルのSFPにパケットを返します。
When packets are received by the IBN on an upper-level path, the classifier parses encapsulated packets for IP and transport-layer (TCP, UDP, etc.) coordinates. State is created, indexed by some or all transport coordinates (typically, {source-IP, destination-IP, source-port, destination-port, and transport protocol}). The state contains, at minimum, the critical fields of the encapsulating SFC header (SPI, SI, MD Type, flags); additional information carried in the packet (metadata, TTL) may also be extracted and saved as state. Note that some fields of a packet may be altered by an SF of the subdomain (e.g., source IP address).
パケットが上位レベルのパスでIBNによって受信されると、分類子はカプセル化されたパケットを解析して、IPおよびトランスポート層（TCP、UDPなど）の座標を求めます。状態が作成され、一部またはすべてのトランスポート座標（通常、{source-IP、destination-IP、source-port、destination-port、およびトランスポートプロトコル}）によってインデックスが作成されます。状態には、少なくとも、カプセル化SFCヘッダーの重要なフィールド（SPI、SI、MDタイプ、フラグ）が含まれます。パケットに含まれる追加情報（メタデータ、TTL）も抽出され、状態として保存されます。パケットの一部のフィールドは、サブドメインのSF（たとえば、送信元IPアドレス）によって変更される場合があることに注意してください。
Note that this state is only accessed by the classifier and terminator functions of the subdomain. Neither the SFFs nor SFs have knowledge of this state; in fact they may be agnostic about being in a subdomain.
この状態にアクセスできるのは、サブドメインの分類機能とターミネーター機能だけです。 SFFもSFもこの状態を認識していません。実際、彼らはサブドメインにいることを知らないかもしれません。
One approach is to ensure that packets are terminated at the end of the chain at the same IBN that classified the packet at the start of the chain. If the packet is returned to a different egress IBN, state must be synchronized between the IBNs.
1つのアプローチは、チェーンの最初でパケットを分類したのと同じIBNで、チェーンの最後でパケットが終了するようにすることです。パケットが別の出力IBNに返される場合、状態はIBN間で同期する必要があります。
When a packet returns to the IBN at the end of a chain (which is the SFP-terminating node of the lower-level chain), the SFC header is removed, the packet is parsed for flow-identifying information, and state is retrieved from within the IBN using the flow-identifying information as index.
パケットがチェーンの最後（下位チェーンのSFP終端ノード）でIBNに戻ると、SFCヘッダーが削除され、フロー識別情報についてパケットが解析され、状態が取得されます。フローを識別する情報をインデックスとして使用して、IBN内で。
State cannot be created by packets arriving from the lower-level chain; when state cannot be found for such packets, they must be dropped.
下位レベルのチェーンから到着するパケットによって状態を作成することはできません。そのようなパケットの状態が見つからない場合は、それらをドロップする必要があります。
This stateful approach is limited to use with SFs that retain the transport coordinates of the packet. This approach cannot be used with SFs that modify those coordinates (e.g., NATs) or otherwise create packets for new coordinates other than those received (e.g., as an HTTP cache might do to retrieve content on behalf of the original flow). In both cases, the fundamental problem is the inability to forward packets when state cannot be found for the packet transport-layer coordinates.
このステートフルなアプローチは、パケットのトランスポート座標を保持するSFでの使用に限定されています。このアプローチは、それらの座標を変更するSF（NATなど）で使用したり、受信した座標以外の新しい座標のパケットを作成したりすることはできません（たとえば、元のフローに代わってHTTPキャッシュがコンテンツを取得するため）。どちらの場合も、基本的な問題は、パケットトランスポート層の座標で状態が見つからない場合にパケットを転送できないことです。
In the stateful approach, there are issues caused by having state, such as how long the state should be maintained as well as whether the state needs to be replicated to other devices to create a highly available network.
ステートフルアプローチでは、状態を維持する必要がある期間や、高可用性ネットワークを作成するために状態を他のデバイスに複製する必要があるかどうかなど、状態を持つことによって引き起こされる問題があります。
It is valid to consider the state to be disposable after failure, since it can be recreated by each new packet arriving from the upper-level domain. For example, if an IBN loses all flow state, the state is recreated by an endpoint retransmitting a TCP packet.
上位レベルのドメインから到着する新しいパケットごとに状態を再作成できるため、障害後に状態を使い捨て可能と見なすことは有効です。たとえば、IBNがすべてのフロー状態を失うと、TCPパケットを再送信するエンドポイントによって状態が再作成されます。
If an SFC domain handles multiple network regions (e.g., multiple private networks), the coordinates may be augmented with additional parameters, perhaps using some metadata to identify the network region.
SFCドメインが複数のネットワーク地域（たとえば、複数のプライベートネットワーク）を処理する場合、おそらくいくつかのメタデータを使用してネットワーク地域を識別する追加のパラメーターで座標を増やすことができます。
In this stateful approach, it is not necessary for the subdomain's control plane to modify paths when upper-level paths are changed. The complexity of the upper-level domain does not cause complexity in the lower-level domain.
このステートフルなアプローチでは、上位レベルのパスが変更されたときにサブドメインのコントロールプレーンがパスを変更する必要はありません。上位レベルのドメインが複雑であっても、下位レベルのドメインが複雑になることはありません。
Since it doesn't depend on NSH in the lower-level domain, this flow-stateful approach can be applied to translation methods of converting NSH to other forwarding techniques (refer to Section 7).
下位レベルドメインのNSHに依存しないため、このフローステートフルアプローチは、NSHを他の転送技術に変換する変換方法に適用できます（セクション7を参照）。
An IBN can push the upper-level SPI and SI (or encoding thereof) into a metadata field of the lower-level encapsulation (e.g., placing upper-level path information into a metadata field of the NSH). When packets exit the lower-level path, the upper-level SPI and SI can be restored from the metadata retrieved from the packet.
IBNは、上位レベルのSPIおよびSI（またはそのエンコード）を下位レベルのカプセル化のメタデータフィールドにプッシュできます（たとえば、上位レベルのパス情報をNSHのメタデータフィールドに配置します）。パケットが下位レベルのパスを出るとき、上位レベルのSPIおよびSIは、パケットから取得されたメタデータから復元できます。
This approach requires the SFs in the path to be capable of forwarding the metadata and appropriately attaching metadata to any packets injected for a flow.
このアプローチでは、パス内のSFがメタデータを転送し、フローに注入されたパケットにメタデータを適切に添付できる必要があります。
Using a new metadata header may inflate packet size when variable-length metadata (NSH MD Type 0x2) is used.
可変長メタデータ（NSH MD Type 0x2）が使用されている場合、新しいメタデータヘッダーを使用すると、パケットサイズが大きくなることがあります。
It is conceivable that the MD Type 0x1 Fixed-Length Context Header field of the NSH is not all relevant to the lower-level domain. In this case, 32 bits of the Fixed-Length Context Header field could be repurposed within the lower-level domain and restored when leaving.
NSHのMD Type 0x1 Fixed-Length Context Headerフィールドがすべて下位レベルドメインに関連しているとは限りません。この場合、32ビットの固定長コンテキストヘッダーフィールドを下位ドメイン内で転用し、退出時に復元できます。
If flags or TTL (see Section 4.4) from the original header also need to be saved, more metadata space will be consumed.
元のヘッダーのフラグまたはTTL（セクション4.4を参照）も保存する必要がある場合、より多くのメタデータスペースが消費されます。
In this metadata approach, it is not necessary for the subdomain's control element to modify paths when upper-level paths are changed. The complexity of the upper-level domain does not increase complexity in the lower-level domain.
このメタデータアプローチでは、上位レベルのパスが変更されたときにサブドメインの制御要素がパスを変更する必要はありません。上位レベルドメインの複雑さは、下位レベルドメインの複雑さを増加させません。
This approach assumes that paths within the subdomain are constrained so that an SPI (of the subdomain) unambiguously indicates the egress SPI and SI (of the upper domain). This allows the original path information to be restored at subdomain egress from a look-up table using the subdomain SPI.
このアプローチは、（サブドメインの）SPIが（上位ドメインの）出力SPIとSIを明確に示すように、サブドメイン内のパスが制約されていることを前提としています。これにより、サブドメインSPIを使用して、ルックアップテーブルからのサブドメイン出口で元のパス情報を復元できます。
Whenever the upper-level domain provisions a path via the lower-level domain, the lower-level domain control plane must provision corresponding paths to traverse the lower-level domain.
上位レベルのドメインが下位レベルのドメインを介してパスをプロビジョニングするときは常に、下位レベルのドメインコントロールプレーンは、下位レベルのドメインを通過するために対応するパスをプロビジョニングする必要があります。
A downside of this approach is that the number of paths in the lower-level domain is multiplied by the number of paths in the upper-level domain that traverse the lower-level domain. That is, a subpath must be created for each combination of upper SPI/SI and lower chain. The number of paths required for lower-level domains will increase exponentially as hierarchy becomes deep.
このアプローチの欠点は、下位ドメインのパスの数に、下位ドメインを横断する上位ドメインのパスの数が掛けられることです。つまり、上位SPI / SIと下位チェーンの組み合わせごとにサブパスを作成する必要があります。下位レベルのドメインに必要なパスの数は、階層が深くなるにつれて指数関数的に増加します。
A further downside of this approach is that it requires upper and lower levels to utilize the same metadata configuration.
このアプローチのもう1つの欠点は、同じメタデータ構成を使用するために上位レベルと下位レベルが必要になることです。
Furthermore, this approach does not allow any information to be stashed away in state or embedded in metadata. For example, the TTL modifications by the lower level cannot be hidden from the upper level.
さらに、このアプローチでは、情報を保管したり、メタデータに埋め込んだりすることはできません。たとえば、下位レベルによるTTL変更を上位レベルから非表示にすることはできません。
When packets arrive at an IBN in the top-level domain, the classifier in the IBN determines the path for the lower-level domain and pushes the new NSH header in front of the original NSH header.
パケットがトップレベルドメインのIBNに到着すると、IBNの分類子が下位レベルドメインのパスを決定し、新しいNSHヘッダーを元のNSHヘッダーの前にプッシュします。
As shown in Figure 3, the Lower-NSH header used to forward packets in the lower-level domain precedes the Upper-NSH header from the top-level domain.
図3に示すように、下位レベルのドメインでパケットを転送するために使用される下位NSHヘッダーは、上位レベルドメインの上位NSHヘッダーよりも前になります。
+---------------------------------+
| Outer-Transport Encapsulation |
+---------------------------------+
| Lower-NSH Header |
+---------------------------------+
| Upper-NSH Header |
+---------------------------------+
| Original Packet |
+---------------------------------+
Figure 3: Encapsulation of NSH within NSH
図3：NSH内のNSHのカプセル化
The traffic with this stack of two NSH headers is to be forwarded according to the Lower-NSH header in the lower-level SFC domain. The Upper-NSH header is preserved in the packets but not used for forwarding. At the last SFF of the chain of the lower-level domain (which resides in the IBN), the Lower-NSH header is removed from the packet, and then the packet is forwarded by the IBN to an SFF of the upper-level domain. The packet will be forwarded in the top-level domain according to the Upper-NSH header.
この2つのNSHヘッダーのスタックを持つトラフィックは、下位レベルのSFCドメインの下位NSHヘッダーに従って転送されます。上位NSHヘッダーはパケットに保持されますが、転送には使用されません。 （IBNに存在する）下位ドメインのチェーンの最後のSFFで、Lower-NSHヘッダーがパケットから削除され、その後、パケットはIBNによって上位ドメインのSFFに転送されます。 。パケットは、Upper-NSHヘッダーに従ってトップレベルドメインで転送されます。
With such encapsulation, Upper-NSH information is carried along the extent of the lower-level chain without modification.
このようなカプセル化により、Upper-NSH情報は変更なしで下位レベルのチェーンの範囲に沿って伝達されます。
A benefit of this approach is that it does not require state in the IBN or configuration to encode fields in metadata. All header fields, including flags and TTL, are easily restored when the chains of the subdomain terminate.
このアプローチの利点は、メタデータのフィールドをエンコードするためにIBNまたは構成の状態を必要としないことです。フラグやTTLを含むすべてのヘッダーフィールドは、サブドメインのチェーンが終了すると簡単に復元されます。
However, the downside is that it does require SFC-aware SFs in the lower-level domain to be able to parse multiple NSH layers. If an SFC-aware SF injects packets, it must also be able to deal with adding appropriate multiple layers of headers to injected packets.
ただし、欠点は、複数のNSHレイヤーを解析できるようにするために、下位レベルのドメインにSFC対応のSFが必要であることです。 SFC対応のSFがパケットを注入する場合は、注入されたパケットに適切な複数のヘッダー層を追加することにも対応できる必要があります。
By increasing packet overhead, nesting may lead to fragmentation or decreased MTU in some networks.
パケットのオーバーヘッドを増やすことにより、ネストによっては、一部のネットワークで断片化またはMTUの減少につながる可能性があります。
The basic idea of this approach is for the IBN to save upper domain encapsulation information such that it can be retrieved by a unique identifier, termed an "hSFC Flow ID".
このアプローチの基本的な考え方は、IBNが上位ドメインのカプセル化情報を保存して、「hSFCフローID」と呼ばれる一意の識別子で取得できるようにすることです。
The hSFC Flow ID is placed, for example, in the NSH Fixed-Length Context Header field of the packet in the lower-level domain, as shown in Figure 4. Likewise, hSFC Flow ID may be encoded as a Variable-Length Context Header field when MD Type 0x2 is used.
hSFCフローIDは、たとえば、図4に示すように、下位ドメインのパケットのNSH固定長コンテキストヘッダーフィールドに配置されます。同様に、hSFCフローIDは、可変長コンテキストヘッダーとしてエンコードできます。 MD Type 0x2を使用する場合のフィールド。
When packets exit the lower-level domain, the IBN uses the hSFC Flow ID to retrieve the appropriate NSH encapsulation for returning the packet to the upper domain. The hSFC Flow ID Context Header is then stripped by the IBN.
パケットが下位レベルのドメインを出ると、IBNはhSFCフローIDを使用して、パケットを上位ドメインに返すための適切なNSHカプセル化を取得します。その後、hSFCフローIDコンテキストヘッダーはIBNによって削除されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hSFC Flow ID |
| Zero Padding or other fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Storing hSFC Flow ID in Lower-Level NSH Fixed-Length Context Header Field ([RFC8300], Section 2.4)
図4：hSFCフローIDを下位レベルのNSH固定長コンテキストヘッダーフィールドに格納する（[RFC8300]、セクション2.4）
Advantages of this approach include:
このアプローチの利点は次のとおりです。
o It does not require state to be based on a 5-tuple, so it works with SFs that change the IP addresses or port numbers of a packet, such as NATs.
o 5タプルに基づく状態である必要はないため、NATなどのパケットのIPアドレスまたはポート番号を変更するSFと連携します。
o It does not require all domains to have the same metadata scheme.
o すべてのドメインが同じメタデータスキームを持つ必要はありません。
o It can be used to restore any upper-domain information, including metadata, flags, and TTL, not just the service path.
o サービスパスだけでなく、メタデータ、フラグ、TTLなどの上位ドメイン情報を復元するために使用できます。
o The lower-level domain only requires a single item of metadata regardless of the number of items of metadata used in the upper domain.
o 下位ドメインでは、上位ドメインで使用されるメタデータのアイテム数に関係なく、メタデータの単一アイテムのみが必要です。
o The SFC-related functionality required by this approach in an SFC-aware SF is able to preserve and apply metadata, which is a requirement that was already present in [RFC8300].
o SFC対応のSFでこのアプローチに必要なSFC関連の機能は、メタデータを保存および適用できます。これは、[RFC8300]にすでに存在していた要件です。
Disadvantages include those of other stateful approaches, including state timeout and synchronization, mentioned in Section 4.1.1.
不利な点には、セクション4.1.1で述べた、状態のタイムアウトや同期など、他のステートフルなアプローチの不利な点があります。
There may be a large number of unique NSH encapsulations to be stored, given that the hSFC Flow ID must represent all of the bits in the upper-level encapsulation. This might consume a lot of memory or
hSFCフローIDが上位レベルのカプセル化のすべてのビットを表す必要がある場合、保存される一意のNSHカプセル化が多数存在する可能性があります。これは多くのメモリを消費するか、
create out-of-memory situations in which hSFC Flow IDs cannot be created or old hSFC Flow IDs are discarded while still in use.
hSFCフローIDを作成できない、または古いhSFCフローIDがまだ使用されているときに破棄されるメモリ不足の状況を作成します。
The SPI or metadata included in a packet received by the IBN may be used as input to reclassification and path selection within a lower-level domain.
IBNが受信したパケットに含まれるSPIまたはメタデータは、下位ドメイン内の再分類およびパス選択への入力として使用できます。
In some cases, the meanings of the various path IDs and metadata must be coordinated between domains for the sake of proper end-to-end SFC operation.
場合によっては、適切なエンドツーエンドのSFC操作のために、さまざまなパスIDとメタデータの意味をドメイン間で調整する必要があります。
One approach is to use well-known identifier values in metadata, maintained in a global registry.
1つのアプローチは、グローバルレジストリで維持されるメタデータで既知の識別子の値を使用することです。
Another approach is to use well-known labels for chain identifiers or metadata, as an indirection to the actual identifiers. The actual identifiers can be assigned by control-plane systems. For example, a subdomain classifier could have a policy, "if pathID = classA then chain packet to path 1234"; the upper-level controller would be expected to configure the concrete upper-level "pathID" for "classA".
別のアプローチは、実際の識別子への間接参照として、チェーン識別子またはメタデータに既知のラベルを使用することです。実際の識別子は、コントロールプレーンシステムによって割り当てることができます。たとえば、サブドメイン分類子は、「pathID = classAの場合、パケットをパス1234にチェーンする」というポリシーを持つことができます。上位レベルのコントローラーは、「classA」の具体的な上位レベルの「pathID」を構成することが期待されます。
Because the IBN acts as an SFC-aware SF to the upper-level domain, it must decrement the Service Index in the NSH headers of the upper-level path. This operation should be undertaken when the packet is first received by the IBN, before applying any of the strategies of Section 4.1, immediately prior to classification.
IBNは上位レベルドメインに対してSFC対応のSFとして機能するため、上位パスのNSHヘッダーのサービスインデックスをデクリメントする必要があります。この操作は、パケットがIBNによって最初に受信されたときに、セクション4.1の戦略を適用する前に、分類の直前に行う必要があります。
The NSH base header contains a TTL field [RFC8300]. There is a choice:
NSHベースヘッダーには、TTLフィールド[RFC8300]が含まれています。選択肢があります：
a subdomain may appear as a pure service function, which should not decrement the TTL from the perspective of the upper-level domain, or
サブドメインは純粋なサービス関数として表示される場合があります。これは、上位レベルのドメインの観点からTTLを減じるべきではありません。
all of the TTL changes within the subdomain may be visible to the upper-level domain.
サブドメイン内のすべてのTTL変更は、上位レベルドメインに表示される場合があります。
Some readers may recognize this as a choice between "pipe" and "uniform" models, respectively [RFC3443].
一部の読者は、これをそれぞれ「パイプ」モデルと「ユニフォーム」モデルの間の選択として認識するかもしれません[RFC3443]。
The network operator should be given control of this behavior, choosing whether to expose the lower-level topology to the upper layer. An implementation may support per-packet policy, allowing some users to perform a layer-transcending trace route, for example.
ネットワークオペレーターには、この動作を制御して、下位レベルのトポロジを上位層に公開するかどうかを選択する必要があります。実装は、パケットごとのポリシーをサポートする場合があり、たとえば、一部のユーザーがレイヤーを超えるトレースルートを実行できるようにします。
The choice affects whether the methods of restoring the paths in Section 4.1 restore a saved version of the TTL or propagate it with the packet. The method of Section 4.1.3 does not permit topology hiding. The other methods of Sections 4.1.1, 4.1.2, 4.1.4, and 4.1.5 have unique methods for restoring saved versions of the TTL.
選択は、セクション4.1でパスを復元する方法が、保存されたバージョンのTTLを復元するか、それをパケットとともに伝搬するかどうかに影響します。セクション4.1.3の方法では、トポロジーを非表示にすることはできません。セクション4.1.1、4.1.2、4.1.4、および4.1.5の他の方法には、TTLの保存されたバージョンを復元するための独自の方法があります。
Within the subdomain (referring to Figure 2), as the classifier receives incoming packets, the upper-level encapsulation is treated according to one of the methods described in Section 4.1 to either statefully store, encode, or nest header information. The classifier then selects the path and metadata for the packet within the subdomain.
サブドメイン内（図2を参照）では、分類子が着信パケットを受信すると、上位レベルのカプセル化がセクション4.1で説明されている方法の1つに従って処理され、ヘッダー情報をステートフルに格納、エンコード、またはネストします。次に、分類子はサブドメイン内のパケットのパスとメタデータを選択します。
One of the goals of the hierarchical approach is to make it easy to have transport-flow-aware service chaining with bidirectional paths. For example, it is desired that for each TCP flow, the client-to-server packets traverse the same SF instances as the server-to-client packets, but in the opposite sequence. We call this "bidirectional symmetry". If bidirectional symmetry is required, it is the responsibility of the control plane to be aware of symmetric paths and configure the classifier to chain the traffic in a symmetric manner.
階層型アプローチの目標の1つは、双方向パスを使用したトランスポートフロー対応のサービスチェーンを簡単に作成できるようにすることです。たとえば、TCPフローごとに、クライアントからサーバーへのパケットがサーバーからクライアントへのパケットと同じSFインスタンスを通過するが、逆の順序で通過することが望ましい。これを「双方向対称性」と呼びます。双方向の対称性が必要な場合、対称パスを認識し、トラフィックを対称的にチェーンするように分類子を構成するのは、コントロールプレーンの責任です。
Another goal of the hierarchical approach is to simplify the mechanisms of scaling SFs in and out. All of the complexities of load-balancing among multiple SFs can be handled within a subdomain, under control of the classifier, allowing the upper-level domain to be oblivious to the existence of multiple SF instances.
階層的アプローチのもう1つの目標は、SFをスケールインおよびスケールアウトするメカニズムを簡素化することです。複数のSF間の負荷分散の複雑さはすべて、分類子の制御下でサブドメイン内で処理できるため、上位ドメインが複数のSFインスタンスの存在に気付かないようにすることができます。
Considering the requirements of bidirectional symmetry and load-balancing, it is useful to have all packets entering a subdomain be received by the same classifier or a coordinated cluster of classifiers. There are both stateful and stateless approaches to ensuring bidirectional symmetry.
双方向の対称性とロードバランシングの要件を考慮すると、サブドメインに入るすべてのパケットが同じ分類子または分類子の調整されたクラスターによって受信されると便利です。双方向の対称性を確保するには、ステートフルとステートレスの両方のアプローチがあります。
Although SFC control protocols have not yet been standardized (as of 2018), from the point of view of hierarchical service function chaining, we have these expectations:
SFC制御プロトコルはまだ標準化されていませんが（2018年現在）、階層的なサービス機能チェーンの観点から、次のような期待があります。
o Each control-plane instance manages a single level of the hierarchy of a single domain.
o 各コントロールプレーンインスタンスは、単一ドメインの階層の単一レベルを管理します。
o Each control plane is agnostic about other levels of the hierarchy. This aspect allows humans to reason about the system within a single domain and control-plane algorithms to use only domain-local inputs. Top-level control does not need visibility to subdomain policies, nor does subdomain control need visibility to upper-level policies. (Top-level control considers a subdomain as though it were an SF.)
o 各コントロールプレーンは、階層の他のレベルにとらわれません。この側面により、人間は単一ドメイン内のシステムについて推論でき、コントロールプレーンアルゴリズムはドメインローカル入力のみを使用します。トップレベルの制御は、サブドメインポリシーの可視性を必要としません。また、サブドメイン制御は、上位レベルのポリシーの可視性を必要としません。 （トップレベルコントロールは、サブドメインをSFであるかのように見なします。）
o Subdomain control planes are agnostic about the control planes of other subdomains. This allows both humans and machines to manipulate subdomain policy without considering policies of other domains.
o サブドメインコントロールプレーンは、他のサブドメインのコントロールプレーンにとらわれません。これにより、人間とマシンの両方が、他のドメインのポリシーを考慮せずにサブドメインポリシーを操作できます。
Recall that the IBN acts as an SFC-aware SF in the upper-level domain (receiving SF instructions from the upper-level control plane) and as a classifier in the lower-level domain (receiving classification rules from the subdomain control plane). In this view, it is the IBN that glues the layers together.
IBNは、上位レベルのドメインではSFC対応のSF（上位レベルのコントロールプレーンからSF命令を受け取る）として機能し、下位レベルのドメインでは分類子として機能する（サブドメインコントロールプレーンから分類ルールを受け取る）ことを思い出してください。このビューでは、レイヤーを接着するのはIBNです。
These expectations are not intended to prohibit network-wide control. A control hierarchy can be envisaged to distribute information and instructions to multiple domains and subdomains. Control hierarchy is outside the scope of this document.
これらの期待は、ネットワーク全体の制御を禁止するものではありません。制御階層は、情報と指示を複数のドメインとサブドメインに配布することを想定できます。コントロール階層は、このドキュメントの範囲外です。
The hierarchical approach can be used for dividing networks into NSH-aware and NSH-unaware domains by converting NSH encapsulation to other forwarding techniques (e.g., 5-tuple-based forwarding with OpenFlow), as shown in Figure 5.
図5に示すように、階層型アプローチは、NSHカプセル化を他の転送技術（OpenFlowによる5タプルベースの転送など）に変換することにより、ネットワークをNSH対応ドメインとNSH非対応ドメインに分割するために使用できます。
* * * * * * * * * * * * * * * * * *
* NSH-aware domain *
* +-------+ +-------+ *
* | SF#1 | | SF#5 | *
* +-o---o-+ +-o---o-+ *
* ^ | ^ | *
* +-|---|-+ +-|---|-+ *
* | |SFF| | | |SFF| | *
* +-|---|-+ +-|---|-+ *
* . | | . *
* +--+ / | | \ *
-->|CF|--' | | '------->
* +--+ v | *
* +---o-----------o---+ *
.*.*.*.*.| / | IBN | \ |*.*.*.
. +-o--o---------o--o-+ .
. | | ^ ^ .
. | +-+ +-+ | .
. +---+ v | +---+ .
. | +-o-----o-+ | .
. | | SF#2 | | .
. | +---------+ | .
. +--+ +--+ .
. | +---------+ | .
. v | v | .
. +-o---o-+ +-o---o-+ .
. | SF#3 | | SF#4 | .
. +-------+ +-------+ .
. NSH-unaware domain .
. . . . . . . . . . . . . . . . . .
SF#1 and SF#5 are NSH aware; SF#2, SF#3, and SF#4 are NSH unaware. In the NSH-unaware domain, packets are conveyed in a format supported by SFs that are deployed there.
SF＃1とSF＃5はNSH対応です。 SF＃2、SF＃3、SF＃4はNSHに対応していません。 NSH非対応ドメインでは、パケットは、そこに展開されているSFでサポートされている形式で伝達されます。
Figure 5: Dividing NSH-Aware and NSH-Unaware Domains
図5：NSH対応ドメインとNSH非対応ドメインの分割
This approach is expected to facilitate service chaining in networks in which NSH-aware and NSH-unaware SFs coexist. Some examples of such situations are:
このアプローチは、NSH対応のSFとNSH非対応のSFが共存するネットワークでサービスチェーンを促進することが期待されています。そのような状況の例は次のとおりです。
o In a period of transition from legacy SFs to NSH-aware SFs
o レガシーSFからNSH対応SFへの移行期間
o Supporting multitenancy
o マルチテナンシーのサポート
In this usage, an IBN classifier is required to have an NSH conversion table for applying packets to appropriate lower-level paths and returning packets to the correct upper-level paths. For example, the following methods would be used for saving/restoring upper-level path information:
この使用法では、パケットを適切な下位レベルのパスに適用し、パケットを正しい上位レベルのパスに戻すためのNSH変換テーブルがIBN分類子に必要です。たとえば、次のメソッドは、上位レベルのパス情報の保存/復元に使用されます。
o Saving SPI and SI in transport-layer flow state (refer to Section 4.1.1)
o SPIとSIをトランスポート層フロー状態で保存（セクション4.1.1を参照）
o Using unique lower-level paths per upper-level NSH coordinates (refer to Section 4.1.3)
o 上位レベルのNSH座標ごとに固有の下位レベルパスを使用する（セクション4.1.3を参照）
Using the unique paths approach would be especially good for translating NSH to a different forwarding technique in the lower level. A single path in the upper level may be branched to multiple paths in the lower level such that any lower-level path is only used by one upper-level path. This allows unambiguous restoration to the upper-level path.
一意のパスアプローチを使用すると、NSHを下位レベルの別の転送技術に変換するのに特に役立ちます。上位レベルの単一のパスを下位レベルの複数のパスに分岐して、下位レベルのパスが1つの上位レベルのパスでのみ使用されるようにすることができます。これにより、上位レベルのパスへの明確な復元が可能になります。
In addition, an IBN might be required to convert metadata contained in the NSH to the format appropriate to the packet in the lower-level path. For example, some legacy SFs identify subscribers based on information about the network topology, such as the VLAN ID (VID), and the IBN would be required to create a VLAN to packets from metadata if the subscriber identifier is conveyed as metadata in upper-level domains.
さらに、NSHに含まれるメタデータを下位パスのパケットに適した形式に変換するためにIBNが必要になる場合があります。たとえば、一部のレガシーSFは、VLAN ID（VID）などのネットワークトポロジーに関する情報に基づいてサブスクライバーを識別し、サブスクライバー識別子が上位のメタデータとして伝達される場合、メタデータからパケットへのVLANを作成するためにIBNが必要になります。レベルドメイン。
Other fundamental functions required for an IBN (e.g., maintaining metadata of upper level or decrementing Service Index) are the same as in normal usage.
IBNに必要なその他の基本的な機能（上位レベルのメタデータの維持やサービスインデックスのデクリメントなど）は、通常の使用方法と同じです。
It is useful to permit metadata to be transferred between levels of a hierarchy. Metadata from an upper level may be useful within a subdomain, and a subdomain may augment metadata for consumption in an upper domain. However, allowing uncontrolled metadata between domains may lead to forwarding failures.
階層のレベル間でメタデータを転送できるようにすると便利です。上位レベルからのメタデータはサブドメイン内で役立つ場合があり、サブドメインは上位ドメインで使用するためにメタデータを補強する場合があります。ただし、ドメイン間で制御されていないメタデータを許可すると、転送エラーが発生する可能性があります。
In order to prevent SFs of lower-level SFC-enabled domains from supplying (illegitimate) metadata, IBNs may be instructed to only permit specific metadata types to exit the subdomain. Such control over the metadata in the upper level is the responsibility of the upper-level control plane.
下位レベルのSFC対応ドメインのSFが（不正な）メタデータを提供しないようにするために、特定のメタデータタイプのみがサブドメインを出ることを許可するようにIBNに指示することができます。上位レベルのメタデータに対するこのような制御は、上位レベルのコントロールプレーンの責任です。
To limit unintentional metadata reaching SFs of lower-level SFC-enabled subdomains, IBNs may be instructed to only permit specific metadata types into the subdomain. Such control of metadata in the lower-level domain is the responsibility of the lower-level control plane.
意図しないメタデータが下位レベルのSFC対応サブドメインのSFに到達するのを制限するために、サブドメインへの特定のメタデータタイプのみを許可するようにIBNに指示することができます。下位レベルドメインでのメタデータのこのような制御は、下位レベルのコントロールプレーンの責任です。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
hSFC makes use of service chaining architecture; hence, it inherits the security considerations described in the architecture document [RFC7665].
hSFCはサービスチェーンアーキテクチャを利用します。したがって、アーキテクチャドキュメント[RFC7665]で説明されているセキュリティの考慮事項を継承します。
Furthermore, hSFC inherits the security considerations of the data-plane protocols (e.g., NSH) and control-plane protocols used to realize the solution.
さらに、hSFCは、ソリューションを実現するために使用されるデータプレーンプロトコル（NSHなど）およびコントロールプレーンプロトコルのセキュリティに関する考慮事項を継承します。
This document describes systems that may be managed by distinct teams that all belong to the same administrative entity. Subdomains must have consistent configurations in order to properly forward traffic. Any protocol designed to distribute the configurations must be secure from tampering. The means of preventing attacks from within a network must be enforced. For example, continuously monitoring the network may allow detecting such misbehaviors. hSFC adheres to the same security considerations as [RFC8300]. Those considerations must be taken into account.
このドキュメントでは、すべてが同じ管理エンティティに属する別個のチームによって管理されるシステムについて説明します。トラフィックを適切に転送するには、サブドメインの構成が一貫している必要があります。構成を配布するように設計されたプロトコルは、改ざんから保護する必要があります。ネットワーク内からの攻撃を防ぐ手段を実施する必要があります。たとえば、ネットワークを継続的に監視すると、そのような不正行為を検出できる場合があります。 hSFCは、[RFC8300]と同じセキュリティ上の考慮事項に準拠しています。これらの考慮事項を考慮する必要があります。
The options in Sections 4.1.2 and 4.1.5 assume the use of a dedicated context header to store information to bind a flow to its upper-level SFP. Such a context header is stripped by the IBN of a subdomain before exiting a subdomain. Additional guards to prevent leaking unwanted context information when entering/exiting a subdomain are discussed in Section 7.2.
セクション4.1.2および4.1.5のオプションは、専用のコンテキストヘッダーを使用して情報を格納し、フローを上位レベルのSFPにバインドすることを前提としています。このようなコンテキストヘッダーは、サブドメインを終了する前に、サブドメインのIBNによって削除されます。サブドメインに出入りするときに不要なコンテキスト情報が漏洩するのを防ぐための追加のガードについては、セクション7.2で説明します。
All of the systems and protocols must be secure from modification by untrusted agents.
すべてのシステムとプロトコルは、信頼できないエージェントによる変更から保護されている必要があります。
Security considerations related to the control plane are discussed in the corresponding control specification documents (e.g., [BGP-CONTROL], [PCEP-EXTENSIONS], or [RADIUS]).
コントロールプレーンに関連するセキュリティの考慮事項は、対応するコントロール仕様のドキュメント（[BGP-CONTROL]、[PCEP-EXTENSIONS]、[RADIUS]など）で説明されています。
Distributing policies among multiple domains may lead to forwarding loops. NSH supports the ability to detect loops (as described in Sections 4.3 and 4.4 of [RFC8300]), but the means of ensuring the consistency of the policies should be enabled at all levels of a domain. Within the context of hSFC, it is the responsibility of the Control Elements at all levels to prevent such (unwanted) loops.
複数のドメイン間でポリシーを配布すると、転送ループが発生する可能性があります。 NSHはループを検出する機能をサポートしています（[RFC8300]のセクション4.3および4.4で説明されています）が、ポリシーの一貫性を保証する手段は、ドメインのすべてのレベルで有効にする必要があります。 hSFCのコンテキスト内では、そのような（不要な）ループを防ぐのは、すべてのレベルの制御要素の責任です。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、and C. Pignataro、Ed。、 "Network Service Header（NSH）"、RFC 8300、DOI 10.17487 / RFC8300、January 2018、<https： //www.rfc-editor.org/info/rfc8300>。
[BGP-CONTROL] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-04, July 2018.
[BGP-CONTROL] Farrel、A.、Drake、J.、Rosen、E.、Uttaro、J。、およびL. Jalil、「BGP Control Plane for NSH SFC」、Work in Progress、draft-ietf-bess-nsh -bgp-control-plane-04、2018年7月。
[PCEP-EXTENSIONS] Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. Tantsura, "PCEP Extensions for Service Function Chaining (SFC)", Work in Progress, draft-wu-pce-traffic-steering-sfc-12, June 2017.
[PCEP-EXTENSIONS] Wu、Q.、Dhody、D.、Boucadair、M.、Jacquenet、C。、およびJ. Tantsura、「PCEP Extensions for Service Function Chaining（SFC）」、Work in Progress、draft-wu- pce-traffic-steering-sfc-12、2017年6月。
[RADIUS] Maglione, R., Trueba, G., and C. Pignataro, "RADIUS Attributes for NSH", Work in Progress, draft-maglione-sfc-nsh-radius-01, October 2016.
[RADIUS] Maglione、R.、Trueba、G。、およびC. Pignataro、「RADIUS Attributes for NSH」、Work in Progress、draft-maglione-sfc-nsh-radius-01、2016年10月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでの存続時間（TTL）処理」、RFC 3443、DOI 10.17487 / RFC3443、2003年1月、<https：// www。 rfc-editor.org/info/rfc3443>。
[USE-CASES] Kumar, S., Tufail, M., Majee, S., Captari, C., and S. Homma, "Service Function Chaining Use Cases In Data Centers", Work in Progress, draft-ietf-sfc-dc-use-cases-06, February 2017.
[使用例] Kumar、S.、Tufail、M.、Majee、S.、Captari、C。、およびS. Homma、「データセンターのサービス機能チェーンの使用例」、作業中、draft-ietf-sfc -dc-use-cases-06、2017年2月。
The advantage of hSFC compared with normal or flat service function chaining is that it can reduce the management complexity significantly. This section discusses examples that show those advantages.
通常またはフラットなサービス機能チェーンと比較したhSFCの利点は、管理の複雑さを大幅に軽減できることです。このセクションでは、これらの利点を示す例について説明します。
In this case, hSFC is used to simplify service function chaining management by reducing the number of SFPs.
この場合、hSFCを使用して、SFPの数を減らすことにより、サービス機能の連鎖管理を簡素化します。
As shown in Figure 6, there are two domains, each with different concerns: a Security Domain that selects SFs based on network conditions and an Optimization Domain that selects SFs based on traffic protocol.
図6に示すように、2つのドメインがあり、それぞれに異なる懸念があります。ネットワークの状態に基づいてSFを選択するセキュリティドメインと、トラフィックプロトコルに基づいてSFを選択する最適化ドメインです。
In this example, there are five security functions deployed in the Security Domain. The Security Domain operator wants to enforce the five different security policies, and the Optimization Domain operator wants to apply different optimizations (either cache or video optimization) to each of these two types of traffic. If we use flat SFC (normal branching), 10 SFPs are needed in each domain. In contrast, if we use hSFC, only five SFPs in Security Domain and two SFPs in Optimization Domain will be required, as shown in Figure 7.
この例では、セキュリティドメインに5つのセキュリティ機能がデプロイされています。 Security Domainオペレーターは5つの異なるセキュリティポリシーを適用し、Optimization Domainオペレーターはこれら2つのタイプのトラフィックのそれぞれに異なる最適化（キャッシュまたはビデオ最適化）を適用したいと考えています。フラットSFC（通常の分岐）を使用する場合、各ドメインに10個のSFPが必要です。対照的に、hSFCを使用する場合、図7に示すように、セキュリティドメインに5つのSFPと最適化ドメインに2つのSFPのみが必要になります。
In the flat model, the number of SFPs is the product of the number of SFs in all of the domains. In the hSFC model, the number of SFPs is the sum of the number of SFs. For example, adding a "bypass" path in the Optimization Domain would cause the flat model to require 15 paths (five more) but cause the hSFC model to require one more path in the Optimization Domain.
フラットモデルでは、SFPの数はすべてのドメインのSFの数の積です。 hSFCモデルでは、SFPの数はSFの数の合計です。たとえば、最適化ドメインに「バイパス」パスを追加すると、フラットモデルでは15パス（5つ以上）が必要になりますが、hSFCモデルでは最適化ドメインでさらに1つのパスが必要になります。
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
Legend: IDS: Intrusion Detection System IPS: Intrusion Prevention System WAF: Web Application Firewall DPI: Deep Packet Inspection
凡例：IDS：侵入検知システムIPS：侵入防止システムWAF：WebアプリケーションファイアウォールDPI：ディープパケットインスペクション
The classifier must select paths that determine the combination of
Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt,
3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5:IPS+Cache, 6:IPS+VideoOpt,
7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache,
10:TrafficMonitor+VideoOpt
Figure 6: Flat SFC (Normal Branching)
図6：フラットSFC（通常の分岐）
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . .
Figure 7: Simplified Path Management with hSFC
図7：hSFCによる簡素化されたパス管理
Hierarchical service function chaining can be used to simplify inter-DC SFC management. In the example of Figure 8, there is a central data center (Central DC) and multiple local data centers (Local DC#1, #2, #3) that are deployed in a geographically distributed manner. All of the data centers are under a single administrative domain.
階層的なサービス機能の連鎖を使用して、DC間SFC管理を簡素化できます。図8の例では、地理的に分散した方法で展開された中央データセンター（中央DC）と複数のローカルデータセンター（ローカルDC＃1、＃2、＃3）があります。すべてのデータセンターは単一の管理ドメインの下にあります。
The central DC may have some service functions that the local DC needs, such that the local DC needs to chain traffic via the central DC. This could be because:
中央DCは、ローカルDCが中央DC経由でトラフィックをチェーンする必要があるように、ローカルDCが必要とするいくつかのサービス機能を持っている場合があります。次の理由が考えられます。
o Some SFs are deployed as dedicated hardware appliances, and there is a desire to lower the cost (both CAPEX and OPEX) of deploying such SFs in all data centers.
o 一部のSFは専用ハードウェアアプライアンスとして展開されており、そのようなSFをすべてのデータセンターに展開するコスト（CAPEXとOPEXの両方）を下げたいという要望があります。
o Some SFs are being trialed or introduced, or they otherwise handle a relatively small amount of traffic. It may be cheaper to manage these SFs in a single central data center and steer packets to the central data center than to manage these SFs in all data centers.
o 一部のSFは試行または導入されているか、そうでなければ比較的少量のトラフィックを処理しています。すべてのデータセンターでこれらのSFを管理するよりも、単一の中央データセンターでこれらのSFを管理し、パケットを中央データセンターに誘導する方が安価な場合があります。
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
Figure 8: Simplify Inter-DC SFC Management
図8：DC間SFC管理の簡素化
For large DC operators, one local DC may have tens of thousands of servers and hundreds of thousands of virtual machines. SFC can be used to manage user traffic. For example, SFC can be used to classify user traffic based on service type, DDoS state, etc.
大規模なDCオペレーターの場合、1つのローカルDCに数万のサーバーと数十万の仮想マシンがある場合があります。 SFCは、ユーザートラフィックの管理に使用できます。たとえば、SFCを使用して、サービスタイプ、DDoS状態などに基づいてユーザートラフィックを分類できます。
In such a large-scale DC, using flat SFC is very complex, requiring a super controller to configure all DCs. For example, any changes to SFs or SFPs in the central DC (e.g., deploying a new SF) would require updates to all of the SFPs in the local DCs accordingly. Furthermore, requirements for symmetric paths add additional complexity when flat SFC is used in this scenario.
このような大規模なDCでは、フラットSFCの使用は非常に複雑であり、すべてのDCを構成するスーパーコントローラーが必要です。たとえば、セントラルDCのSFまたはSFPに変更を加える（たとえば、新しいSFを展開する）場合は、それに応じてローカルDCのすべてのSFPを更新する必要があります。さらに、このシナリオでフラットSFCを使用する場合、対称パスの要件によりさらに複雑になります。
Conversely, if using hierarchical SFC, each DC can be managed independently to significantly reduce management complexity. SFPs between DCs can represent abstract notions without regard to details within DCs. Independent controllers can be used for the top level (getting packets to pass the correct DCs) and local levels (getting packets to specific SF instances).
逆に、階層型SFCを使用している場合は、各DCを個別に管理して、管理の複雑さを大幅に軽減できます。 DC間のSFPは、DC内の詳細に関係なく、抽象的な概念を表すことができます。独立したコントローラーは、トップレベル（パケットが正しいDCを渡すようにする）とローカルレベル（特定のSFインスタンスにパケットを渡す）に使用できます。
Acknowledgements
謝辞
The concept of Hierarchical Service Path Domains was introduced in "Analysis on Forwarding Methods for Service Chaining" (August 2016) as a means of improving scalability of service chaining in large networks.
階層型サービスパスドメインの概念は、大規模ネットワークでのサービスチェーンのスケーラビリティを向上させる手段として、「サービスチェーンの転送方法の分析」（2016年8月）で紹介されました。
The concept of nesting NSH headers within lower-level NSH was contributed by Ting Ao. The concept originally appeared in "Hierarchical SFC for DC Interconnection" (April 2016) as a means of creating hierarchical SFC in a data center.
下位レベルのNSH内にNSHヘッダーをネストする概念は、Ting Aoによって提供されました。この概念は、データセンターで階層型SFCを作成する手段として、「DC相互接続用の階層型SFC」（2016年4月）で最初に登場しました。
We thank Dapeng Liu for contributing the DC examples in the Appendix.
付録のDCの例を提供してくれたDapeng Liuに感謝します。
The Stateful/Metadata Hybrid section was contributed by Victor Wu.
ステートフル/メタデータハイブリッドセクションは、Victor Wuによって寄稿されました。
The authors would also like to thank the following individuals for providing valuable feedback:
著者はまた、貴重なフィードバックを提供してくれた次の方々に感謝します。
Ron Parker Christian Jacquenet Jie Cao Kyle Larose
ろん ぱｒけｒ Ｃｈりｓちあん じゃｃくえねｔ じえ かお Ｋｙぇ ぁろせ
Thanks to Ines Robles, Sean Turner, Vijay Gurbani, Ben Campbell, and Benjamin Kaduk for their review.
Ines Robles、Sean Turner、Vijay Gurbani、Ben Campbell、Benjamin Kadukのレビューに感謝します。
Authors' Addresses
著者のアドレス
David Dolson Sandvine Waterloo, ON Canada
デビッドドルソンサンドバインウォータールー、カナダ
Email: ddolson@acm.org
Shunsuke Homma NTT 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan
しゅんすけ ほっま んっｔ ３ー９ー１１、 みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Email: homma.shunsuke@lab.ntt.co.jp
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
Diego R. Lopez Telefonica I + D Don Ramon de la Cruz、82マドリード28006スペイン
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Mohamed Boucadair Orange Rennes 35000 France
Mohamed Boucadair Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com