[要約] RFC 7665は、サービス機能チェイニング（SFC）アーキテクチャに関する標準化ドキュメントであり、ネットワーク内の複数のサービス機能を連鎖させるためのフレームワークを提供しています。その目的は、ネットワークサービスの柔軟性と効率性を向上させることです。
Internet Engineering Task Force (IETF) J. Halpern, Ed.
Request for Comments: 7665 Ericsson
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
October 2015
Service Function Chaining (SFC) Architecture
サービス機能チェーン（SFC）アーキテクチャ
Abstract
概要
This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.
このドキュメントでは、ネットワーク内のサービスファンクションチェーン（SFC）の仕様、作成、および継続的なメンテナンスのためのアーキテクチャについて説明します。 IETFで標準化されるものに重点を置いて、SFCの展開による複合サービスの構築に使用されるアーキテクチャの概念、原則、およびコンポーネントが含まれています。このドキュメントは、ソリューション、プロトコル、または既存のプロトコルへの拡張を提案しません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7665.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7665で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Specification of Requirements . . . . . . . . . . . . . . 5
1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 6
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 8
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 9
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 10
2.3.1. Service Function Chains, Service Function Paths, and
Rendered Service Path . . . . . . . . . . . . . . . . 11
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 12
4. Core SFC Architecture Components . . . . . . . . . . . . . . 13
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 14
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 15
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 15
4.3.1. Transport-Derived SFF . . . . . . . . . . . . . . . . 17
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 17
4.5. Network Overlay and Network Components . . . . . . . . . 18
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 19
4.8. Reclassification and Branching . . . . . . . . . . . . . 19
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 20
5. Additional Architectural Concepts . . . . . . . . . . . . . . 21
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 21
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 21
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 22
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 23
5.5. Load-Balancing Considerations . . . . . . . . . . . . . . 23
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 24
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
The delivery of end-to-end services often requires various service functions. These include traditional network service functions such as firewalls and traditional IP Network Address Translators (NATs), as well as application-specific functions. The definition and instantiation of an ordered set of service functions and subsequent "steering" of traffic through them is termed Service Function Chaining (SFC).
エンドツーエンドのサービスを提供するには、多くの場合、さまざまなサービス機能が必要です。これには、ファイアウォールや従来のIPネットワークアドレストランスレータ（NAT）などの従来のネットワークサービス機能や、アプリケーション固有の機能が含まれます。順序付けされた一連のサービス機能の定義とインスタンス化、およびそれらを介したトラフィックの後続の「ステアリング」は、サービス機能チェーン（SFC）と呼ばれます。
This document describes an architecture used for the creation and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components, with a focus on those to be standardized in the IETF. SFCs enable composite services that are constructed from one or more service functions.
このドキュメントでは、ネットワーク内のサービスファンクションチェーン（SFC）の作成と継続的なメンテナンスに使用されるアーキテクチャについて説明します。 IETFで標準化されるものに焦点を当てた、アーキテクチャの概念、原則、およびコンポーネントが含まれています。 SFCは、1つ以上のサービス機能から構成される複合サービスを有効にします。
An overview of the issues associated with the deployment of end-to-end service function chains, abstract sets of service functions and their ordering constraints that create a composite service, and the subsequent "steering" of traffic flows through said service functions, is described in [RFC7498].
エンドツーエンドのサービス関数チェーンの展開、サービス関数の抽象的なセット、および複合サービスを作成するそれらの順序付け制約に関連する問題の概要、およびその後の前記サービス関数を介したトラフィックフローの「ステアリング」について説明します。 [RFC7498]。
The current service function deployment models are relatively static, coupled to network topology and physical resources, greatly reducing or eliminating the ability of an operator to introduce new services or dynamically create service function chains. This architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity.
現在のサービス機能展開モデルは比較的静的であり、ネットワークトポロジと物理リソースに結合されているため、オペレーターが新しいサービスを導入したり、サービス機能チェーンを動的に作成したりする能力が大幅に低下または排除されます。このアーキテクチャは、トポロジの独立性や構成の複雑さなど、既存のサービス展開の問題のある側面に対処するモデルを提供します。
This document defines the architecture for Service Function Chaining (SFC) as standardized in the IETF. The SFC architecture is predicated on topological independence from the underlying forwarding topology.
このドキュメントでは、IETFで標準化されているService Function Chaining（SFC）のアーキテクチャを定義しています。 SFCアーキテクチャは、基礎となる転送トポロジーからのトポロジーの独立性を前提としています。
In this architecture, packets are classified on ingress for handling by the required set of Service Functions (SFs) in the SFC-enabled domain and are then forwarded through that set of functions for processing by each function in turn. Packets may be reclassified as a result of this processing.
このアーキテクチャでは、パケットは、SFC対応ドメインで必要なサービス機能（SF）のセットによる処理のために入口で分類され、次に、各機能による処理のためにその機能のセットを通じて転送されます。この処理の結果、パケットが再分類される場合があります。
The architecture described in this document is independent of the planned usage of the network and deployment context and thus, for example, is applicable to both fixed and mobile networks as well as being useful in many data center applications.
このドキュメントで説明されているアーキテクチャは、ネットワークの使用計画や展開のコンテキストとは無関係であるため、たとえば、固定ネットワークとモバイルネットワークの両方に適用でき、多くのデータセンターアプリケーションで役立ちます。
The architecture described herein is assumed to be applicable to a single network administrative domain. While it is possible for the architectural principles and components to be applied to inter-domain SFCs, these are left for future study.
ここで説明するアーキテクチャは、単一のネットワーク管理ドメインに適用できると想定されています。アーキテクチャの原則とコンポーネントをドメイン間SFCに適用することは可能ですが、これらは将来の研究に残されています。
The following assumptions are made:
次の仮定が行われます。
o There is no standard definition or characterization applicable to all SFs, and thus the architecture considers each SF as an opaque processing element.
o すべてのSFに適用できる標準の定義または特性はありません。したがって、アーキテクチャは各SFを不透明な処理要素と見なします。
o There is no global or standard list of SFs enabled in a given administrative domain. The set of SFs enabled in a given domain is a function of the currently active services that may vary with time and according to the networking environment.
o 特定の管理ドメインで有効になっているSFのグローバルリストまたは標準リストはありません。特定のドメインで有効になっているSFのセットは、現在アクティブなサービスの機能であり、時間やネットワーク環境によって異なる場合があります。
o There is no global or standard SF chaining logic. The ordered set of SFs that needs to be applied to deliver a given service is specific to each administrative entity.
o グローバルまたは標準のSFチェーンロジックはありません。特定のサービスを提供するために適用する必要があるSFの順序付けされたセットは、各管理エンティティに固有です。
o The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain.
o SFのチェーンとそれらを呼び出す基準は、SF対応ドメインを運用する各管理エンティティに固有です。
o Several SF chaining policies can be simultaneously applied within an administrative domain to meet various business requirements.
o いくつかのSFチェーンポリシーを管理ドメイン内で同時に適用して、さまざまなビジネス要件を満たすことができます。
o The underlay is assumed to provide the necessary connectivity to interconnect the Service Function Forwarders (SFFs; see Section 1.4), but the architecture places no constraints on how that connectivity is realized other than it have the required bandwidth, latency, and jitter to support the SFC.
o アンダーレイは、Service Function Forwarder（SFF;セクション1.4を参照）を相互接続するために必要な接続を提供すると想定されていますが、アーキテクチャは、接続を実現する方法に制約を課しません。 SFC。
o No assumption is made on how Forwarding Information Bases (FIBs) and Routing Information Bases (RIBs) of involved nodes are populated.
o 関係するノードの転送情報ベース（FIB）とルーティング情報ベース（RIB）がどのように入力されるかについては想定されていません。
o How to bind traffic to a given SF chain is policy-based.
o トラフィックを特定のSFチェーンにバインドする方法はポリシーベースです。
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]で説明されているように解釈されます。
Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a "composite service". The term "service" is used to denote a "network service" in the context of this document.
ネットワークサービス：1つ以上のサービス機能を使用して提供される、オペレーターによって提供されるオファリング。これは「複合サービス」とも呼ばれます。 「サービス」という用語は、このドキュメントのコンテキストでは「ネットワークサービス」を示すために使用されます。
Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a "firewall". Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted.
注：このドキュメント以外では、「サービス」という用語はさまざまな定義で過負荷になっています。たとえば、一部のサービスは事業者のネットワーク内のいくつかの要素で構成されるオファリングですが、他のサービス、より具体的にはネットワークサービスは「ファイアウォール」などの個別の要素です。従来、このようなサービスは（後者の意味で）一連のサービス機能をホストし、サービスがホストされるネットワークロケーターを備えています。
Classification: Locally instantiated matching of traffic flows against policy for subsequent application of the required set of network service functions. The policy may be customer/network/ service specific.
分類：必要なネットワークサービス機能のセットを後で適用するために、ポリシーに対してトラフィックフローをローカルにインスタンス化して照合します。ポリシーは、顧客/ネットワーク/サービス固有である場合があります。
Classifier: An element that performs Classification.
Classifier：分類を実行する要素。
Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for service function chain.
サービス関数チェーン（SFC）：サービス関数チェーンは、分類の結果として選択されたパケットおよび/またはフレームおよび/またはフローに適用する必要がある抽象サービス関数の順序付けされたセットと順序付け制約を定義します。抽象サービス機能の例は「ファイアウォール」です。アーキテクチャは複数のブランチにコピーするSFCを許可し、サービス機能を適用する必要がある順序に柔軟性がある場合も許可するため、暗黙の順序は直線的な進行ではない場合があります。 「サービスチェーン」という用語は、サービス機能チェーンの省略形としてよく使用されます。
Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain.
サービス機能（SF）：受信したパケットの特定の処理を担当する機能。サービス機能は、プロトコルスタックのさまざまなレイヤー（ネットワークレイヤーや他のOSIレイヤーなど）で動作できます。論理コンポーネントとして、サービス機能は仮想要素として実現するか、物理ネットワーク要素に組み込むことができます。 1つ以上のサービス機能を同じネットワーク要素に組み込むことができます。同じ管理ドメインにサービス機能の複数のオカレンスが存在する可能性があります。
One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer.
付加価値サービスの提供には、1つ以上のサービス機能を含めることができます。抽象サービス機能の完全ではないリストには、ファイアウォール、WANおよびアプリケーションアクセラレーション、ディープパケットインスペクション（DPI）、合法的傍受（LI）、サーバーロードバランシング、NAT44 [RFC3022]、NAT64 [RFC6146]、NPTv6 [RFC6296]、 HOST_IDインジェクション、HTTPヘッダーエンリッチメント関数、TCPオプティマイザー。
An SF may be SFC encapsulation aware (that is, it receives and acts on information in the SFC encapsulation) or unaware (in which case, data forwarded to the SF does not contain the SFC encapsulation). This is often referred to as "SFC aware" and "SFC unaware", respectively.
SFはSFCカプセル化に対応している（つまり、SFCカプセル化の情報を受信して処理する）か、または認識しない（この場合、SFに転送されるデータにSFCカプセル化が含まれていない）場合があります。これは、それぞれ「SFC対応」および「SFC非対応」と呼ばれることがよくあります。
Service Function Forwarder (SFF): A service function forwarder is responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, an SFF is responsible for delivering traffic to a classifier when needed and supported, transporting traffic to another SFF (in the same or different type of overlay), and terminating the Service Function Path (SFP).
サービス機能フォワーダー（SFF）：サービス機能フォワーダーは、SFCカプセル化で運ばれる情報に従って1つ以上の接続されたサービス機能にトラフィックを転送し、SFから戻ってくるトラフィックを処理します。さらに、SFFは、必要に応じてサポートされるときにトラフィックを分類子に配信し、（同じまたは異なるタイプのオーバーレイで）別のSFFにトラフィックを転送し、Service Function Path（SFP）を終端します。
Metadata: Provides the ability to exchange context information between classifiers and SFs, and among SFs.
メタデータ：分類子とSF間、およびSF間でコンテキスト情報を交換する機能を提供します。
Service Function Path (SFP): The service function path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network.
サービス機能パス（SFP）：サービス機能パスは、特定のサービス機能パスに割り当てられたパケットがどこに移動する必要があるかについての制約付き仕様です。正確な場所を特定できるほど制約がある場合もありますが、特定性が低い場合もあります。 SFPは、配信される抽象サービス機能のシーケンスとしてのサービスチェーンの完全に抽象的な概念と、実際にネットワークを通過するときにパケットがアクセスするSFF / SFの完全に指定された概念との間の間接レベルを提供します。制御コンポーネントがこのレベルの間接参照を指定できるようにすることで、オペレーターは、ネットワークに委任されるSFF / SF選択権限の程度を制御できます。
SFC Encapsulation: The SFC encapsulation provides, at a minimum, SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries metadata including data-plane context information.
SFCカプセル化：SFCカプセル化は、少なくとも、SFP識別を提供し、SFFやSFC対応のSFなどのSFC対応機能によって使用されます。 SFCカプセル化は、ネットワークパケット転送には使用されません。 SFP識別に加えて、SFCカプセル化には、データプレーンコンテキスト情報を含むメタデータが含まれます。
Rendered Service Path (RSP): Within an SFP, packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit.
レンダリングされたサービスパス（RSP）：SFP内では、パケット自体はもちろん、ネットワーク内の特定の場所との間で送信され、SFFとSFの特定のシーケンスを訪れます。パケットによるネットワーク内の特定のSFFおよびSFへの実際の訪問のシーケンスは、レンダリングされたサービスパス（RSP）と呼ばれます。この定義は、ソリューションがパケットがアクセスする場所の実際のシーケンスについて議論する必要がある場合など、後のドキュメントで使用するためにここに含まれています。
SFC-Enabled Domain: A network or region of a network that implements SFC. An SFC-enabled domain is limited to a single network administrative domain.
SFC対応ドメイン：SFCを実装するネットワークまたはネットワークの領域。 SFC対応ドメインは、単一のネットワーク管理ドメインに制限されています。
SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements.
SFCプロキシ：SFC非対応サービス機能に代わってSFCカプセル化を削除および挿入します。 SFCプロキシは論理要素です。
The following sections describe the foundational concepts of service function chaining and the SFC architecture.
次のセクションでは、サービス機能の連鎖とSFCアーキテクチャの基本的な概念について説明します。
Service function chaining enables the creation of composite (network) services that consist of an ordered set of SFs that must be applied to packets and/or frames and/or flows selected as a result of classification. Each SF is referenced using an identifier that is unique within an SF-enabled domain.
サービス機能の連鎖により、分類の結果として選択されたパケットおよび/またはフレームおよび/またはフローに適用する必要がある順序付けられたSFのセットで構成される複合（ネットワーク）サービスの作成が可能になります。各SFは、SF対応ドメイン内で一意の識別子を使用して参照されます。
Service function chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities.
サービス機能の連鎖は、選択されたトラフィックへのSFの順序付けされたセットの適用以上のものを提供する概念です。むしろ、それらのSFの動的な順序付けとトポロジーの独立性、および参加エンティティ間のメタデータの交換を可能にする方法でSFを展開する方法について説明します。
In most networks, services are constructed as abstract sequences of SFs that represent SFCs. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed. Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF. Such graph nodes (SFs) can be part of zero, one, or many SFCs. A given graph node (SF) can appear one time or multiple times in a given SFC.
ほとんどのネットワークでは、サービスはSFCを表すSFの抽象的なシーケンスとして構築されます。大まかに言えば、SFCはサービスの抽象ビューであり、必要なSFのセットと、それらを実行する必要がある順序を指定します。図1に示すように、グラフはSFCを定義します。各グラフノードは、少なくとも1つの抽象SFの必要な存在を表します。そのようなグラフノード（SF）は、0、1、または多くのSFCの一部になることができます。特定のグラフノード（SF）は、特定のSFCで1回または複数回表示されることがあります。
SFCs can start from the origination point of the service function graph (i.e., node 1 in Figure 1), or from any subsequent node in the graph. As shown, SFs may therefore become branching nodes in the graph, with those SFs selecting edges that move traffic to one or more branches. The top and middle graphs depict such a case, where a second classification event occurs after node 2, and a new graph is selected (i.e., node 3 instead of node 6). The bottom graph highlights the concept of a cycle, in which a given SF (e.g., node 7 in the depiction) can be visited more than once within a given service chain. An SFC can have more than one terminus.
SFCは、サービス関数グラフの起点（つまり、図1のノード1）から開始することも、グラフ内の後続のノードから開始することもできます。したがって、示されているように、SFはグラフの分岐ノードになる可能性があり、これらのSFはトラフィックを1つ以上の分岐に移動するエッジを選択します。上部と中央のグラフは、ノード2の後に2番目の分類イベントが発生し、新しいグラフが選択された（つまり、ノード6ではなくノード3）場合を示しています。下のグラフは、サイクルの概念を強調しています。このサイクルでは、特定のサービスチェーン内で特定のSF（図のノード7など）に複数回アクセスできます。 SFCは複数の終端を持つことができます。
,-+-. ,---. ,---. ,---.
/ \ / \ / \ / \
( 1 )+--->( 2 )+---->( 6 )+---->( 8 )
\ / \ / \ / \ /
`---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
Figure 1: Service Function Chain Graphs
図1：サービス関数チェーングラフ
The concepts of classification, reclassification, and branching are covered in subsequent sections of this architecture (see Sections 4.7 and 4.8).
分類、再分類、および分岐の概念については、このアーキテクチャの後続のセクションで説明します（セクション4.7および4.8を参照）。
SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic.
SFCは単方向または双方向です。単方向SFCでは、順序付けられたSFを介してトラフィックを一方向（sf1-> sf2-> sf3）に転送する必要がありますが、双方向SFCでは対称パス（sf1-> sf2-> sf3およびsf3-> sf2-> sf1）が必要です。 、そしてSFインスタンスは反対方向に同じです。ハイブリッドSFCには、単方向と双方向の両方のSFCの属性があります。つまり、一部のSFは対称トラフィックを必要としますが、他のSFはリバーストラフィックを処理しないか、対応するフォワードトラフィックから独立しています。
SFCs may contain cycles; that is traffic may need to traverse one or more SFs within an SFC more than once. Solutions will need to ensure suitable disambiguation for such situations.
SFCにはサイクルが含まれる場合があります。つまり、トラフィックはSFC内の1つ以上のSFを複数回通過する必要がある場合があります。ソリューションは、そのような状況に適切な明確化を確実にする必要があります。
The architectural allowance that is made for SFPs that delegate choice to the network for which SFs and/or SFFs a packet will visit creates potential issues here. A solution that allows such delegation needs to also describe how the solution ensures that those service chains requiring service function chain symmetry can achieve that.
パケットがアクセスするSFまたはSFF、あるいはその両方のネットワークに選択を委任するSFPに対して行われるアーキテクチャ上の許容量は、ここで潜在的な問題を引き起こします。このような委任を可能にするソリューションでは、サービス機能チェーンの対称性を必要とするサービスチェーンがそれを確実に実現できるようにする方法も説明する必要があります。
Further, there are state trade-offs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example:
さらに、対称的な状態のトレードオフがあります。対称性は、SFFと分類機能に応じていくつかの方法で実現できます。場合によっては、「ミラーリングされた」分類（つまり、ソースから宛先へ、および宛先からソースへ）ポリシーがデプロイされますが、他の例では、分類子間の共有状態を使用して、対称フローが正しく識別され、必要に応じて操作されます。 SFP。高レベルでは、さまざまな一般的なケースがあります。網羅的ではない方法で、たとえば次のような場合があります。
o A single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier.
o 単一の分類子（または少数の分類子）。この場合、着信フローと発信フローの両方が同じ分類子で認識されるため、分類子内部の内部メカニズムによって同期を実行できます。
o Stateful classifiers where several classifiers may be clustered and share state.
o 複数の分類子をクラスター化して状態を共有できるステートフル分類子。
o Fully distributed classifiers, where synchronization needs to be provided through unspecified means.
o 完全に分散された分類子。不特定の手段を通じて同期を提供する必要があります。
o A classifier that learns state from the egress packets/flows that is then used to provide state for the return packets/flow.
o 出力パケット/フローから状態を学習する分類子。これは、戻りパケット/フローの状態を提供するために使用されます。
o Symmetry may also be provided by stateful forwarding logic in the SFF in some implementations.
o 一部の実装では、SFFのステートフル転送ロジックによって対称性を提供することもできます。
This is a non-comprehensive list of common cases.
これは一般的なケースの包括的なリストではありません。
A Service Function Path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and operational constraints to the abstract requirements of a service chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes.
サービス機能パス（SFP）は、サービスチェーンで使用されるメカニズムであり、サービスチェーン（SFC）の抽象的な要件に、より詳細なポリシーと運用上の制約を適用した結果を表現します。このアーキテクチャでは、SFPの特定度は必須ではありません。アーキテクチャ上、同じSFC対応ドメイン内では、一部のSFPが完全に指定され、そのSFPを使用するパケットがどのSFFとどのSFにアクセスするかが正確に選択されますが、他のSFPは非常にあいまいで、SFFにSFCを実現するために使用される正確な一連のステップ。特異性はこれらの両極端の間のどこにあってもよい。
As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP specifies that any order of SFF and SF may be used as long as it is within Data Center 1, and where the second SFP allows the same latitude, but only within Data Center 2.
このような中間的な特異性の例として、特定のSFCに関連付けられた2つのSFPがある場合があります。1つのSFPは、データセンター1内にある限り、SFFとSFの任意の順序を使用できることを指定し、2番目のSFPで許可されます。同じ緯度ですが、データセンター2内のみです。
Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs associated with a single SFC.
したがって、SFPの選択または作成のポリシーとロジック（ソリューションによって異なります）は、元のSFCの制約バージョンと考えられるものを生成します。複数のポリシーが同じSFCを使用する異なるトラフィックに適用される可能性があるため、単一のSFCに関連付けられた複数のSFPが存在する可能性もあります。
The architecture allows for the same SF to be reachable through multiple SFFs. In these cases, some SFPs may constrain which SFF is used to reach which SF, while some SFPs may leave that decision to the SFF itself.
このアーキテクチャでは、複数のSFFを通じて同じSFに到達できます。これらの場合、一部のSFPは、どのSFFがどのSFに到達するために使用されるかを制限する場合がありますが、一部のSFPは、その決定をSFF自体に任せる場合があります。
Further, the architecture allows for two or more SFs to be attached to the same SFF, and possibly connected via internal means allowing more effective communication. In these cases, some solutions or deployments may choose to use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for such an environment. This must be coordinated with the SFF so that it can properly perform its job. Implementation details of such mechanisms are considered out of scope for this document, and can include a spectrum of methods: for example, situations including all next-hops explicitly, others where a list of possible next-hops is provided and the selection is local, or cases with just an identifier, where all resolution is local.
さらに、このアーキテクチャでは、2つ以上のSFを同じSFFに接続し、内部手段を介して接続して、より効果的な通信を可能にすることができます。これらの場合、一部のソリューションまたは展開では、そのような環境に最適化された、何らかの形式の内部プロセス間またはVM間メッセージング（仮想スイッチングエレメントの背後にある通信）の使用を選択する場合があります。これは、SFFと連携して、適切にジョブを実行できるようにする必要があります。そのようなメカニズムの実装の詳細は、このドキュメントの範囲外と見なされ、さまざまな方法を含めることができます。たとえば、すべてのネクストホップを明示的に含む状況、可能なネクストホップのリストが提供され、選択がローカルである状況、または、すべての解決がローカルである、識別子のみのケース。
This architecture also allows the same SF to be part of multiple SFPs.
このアーキテクチャでは、同じSFを複数のSFPの一部にすることもできます。
2.3.1. Service Function Chains, Service Function Paths, and Rendered Service Path
2.3.1. サービス関数チェーン、サービス関数パス、およびレンダリングされたサービスパス
As an example of this progressive refinement, consider a Service Function Chain (SFC) that states that packets using this chain should be delivered to a firewall and a caching engine.
この漸進的な改良の例として、このチェーンを使用するパケットをファイアウォールおよびキャッシングエンジンに配信する必要があることを示すサービス機能チェーン（SFC）を検討してください。
A Service Function Path (SFP) could refine this, considering that this architecture does not mandate the degree of specificity an SFP has to have. It might specify that the firewall and caching engine are both to be in a specific data center (e.g., in DC1), or it might specify exactly which instance of each firewall and caching engine is to be used.
サービス機能パス（SFP）は、SFPが持つ必要のある特定の程度をこのアーキテクチャーが義務付けていないことを考慮して、これを改良できます。ファイアウォールとキャッシングエンジンの両方を特定のデータセンター（DC1など）に配置するように指定することも、各ファイアウォールとキャッシングエンジンのどのインスタンスを使用するかを正確に指定することもできます。
The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs that the packets will actually visit. So if the SFP picked the DC, the RSP would be more specific.
レンダリングされたサービスパス（RSP）は、パケットが実際にアクセスするSFFとSFの実際のシーケンスです。したがって、SFPがDCを選択した場合、RSPはより具体的になります。
Service function chaining is predicated on several key architectural principles:
サービス機能の連鎖は、いくつかの主要なアーキテクチャの原則に基づいています。
1. Topological independence: No changes to the underlay network forwarding topology -- implicit, or explicit -- are needed to deploy and invoke SFs or SFCs.
1. トポロジーの独立性：SFまたはSFCをデプロイして呼び出すために、アンダーレイネットワーク転送トポロジー（暗黙的または明示的）に変更を加える必要はありません。
2. Plane separation: Dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding).
2. プレーンの分離：SFPの動的な実現は、パケット処理操作（パケット転送など）から分離されています。
3. Classification: Traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e., forming a service graph), thus enabling changes/updates to the SFC by SFs.
3. 分類：分類ルールを満たすトラフィックは、特定のSFPに従って転送されます。たとえば、1つのアドレスからすべてのトラフィックをSFPに転送する明示的な転送エントリと同じくらい簡単に分類できます。 SFC内で複数の分類ポイントが可能である（つまり、サービスグラフを形成する）ため、SFによるSFCの変更/更新が可能になります。
Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, it can be the result of high-level inspections, or it can come from external systems.
分類はさまざまな粒度で発生する可能性があります。たとえば、分類には5タプル、トランスポートポートまたはポートのセット、パケットペイロードの一部を使用できます。これは、高レベルの検査の結果である場合や、外部システムから取得される場合があります。
4. Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration).
4. 共有メタデータ：メタデータ/コンテキストデータは、SFと分類子の間、SF間、および外部システムとSF間で共有できます（オーケストレーションなど）。
One use of metadata is to provide and share the result of classification (that occurs within the SFC-enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. Metadata can also share SF output along the SFP.
メタデータの用途の1つは、SFPに沿って分類の結果（SFC対応ドメイン内またはドメイン外で発生）を提供および共有することです。たとえば、外部リポジトリがユーザー/サブスクライバー情報をサービスチェーン分類子に提供する場合があります。この分類子は、必要なSFに配信するためにSFCカプセル化にその情報を課すことができます。 SFは、ローカルポリシーの決定にユーザー/サブスクライバー情報を利用できます。メタデータは、SFPに沿ってSF出力を共有することもできます。
5. Service definition independence: The SFC architecture does not depend on the details of SFs themselves.
5. サービス定義の独立性：SFCアーキテクチャは、SF自体の詳細には依存しません。
6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs.
6. サービス機能チェーンの独立性：SFCの作成、変更、または削除は、他のSFCに影響を与えません。 SFPについても同様です。
7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria.
7. 異種制御/ポリシーポイント：このアーキテクチャにより、SFは独立したメカニズム（このドキュメントの範囲外）を使用して、ローカルポリシーと（必要な場合は）ローカル分類基準を設定および解決できます。
The SFC Architecture is built out of architectural building blocks that are logical components; these logical components are classifiers, Service Function Forwarders (SFFs), the Service Functions (SFs) themselves, and SFC proxies. While this architecture describes functionally distinct logical components and promotes transport independence, they could be realized and combined in various ways in deployed products, and could be combined with an overlay.
SFCアーキテクチャは、論理コンポーネントであるアーキテクチャビルディングブロックから構築されています。これらの論理コンポーネントは、分類子、Service Function Forwarder（SFF）、Service Functions（SF）自体、およびSFCプロキシです。このアーキテクチャは機能的に異なる論理コンポーネントを記述し、トランスポートの独立性を促進しますが、それらは展開された製品でさまざまな方法で実現および結合でき、オーバーレイと結合できます。
They are interconnected using the SFC encapsulation. This results in a high-level logical architecture of an SFC-enabled domain that comprises:
これらは、SFCカプセル化を使用して相互接続されます。これにより、SFC対応ドメインの高レベルの論理アーキテクチャが構成されます。
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +--------------+ +------------------~~~
. | Service | SFC | Service +---+ +---+
. |Classification| Encapsulation | Function |sf1|...|sfn|
+---->| Function |+---------------->| Path +---+ +---+
. +--------------+ +------------------~~~
. SFC-enabled Domain
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2: Service Function Chain Architecture
図2：サービス機能チェーンのアーキテクチャ
The following subsections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how some of these architectural components interact is provided in Figure 3:
以下のサブセクションでは、SFCアーキテクチャーの基礎を形成する各論理コンポーネントの詳細について説明します。これらのアーキテクチャコンポーネントの相互作用の詳細な概要を図3に示します。
+----------------+ +----------------+
| SFC-aware | | SFC-unaware |
|Service Function| |Service Function|
+-------+--------+ +-------+--------+
| |
SFC Encapsulation No SFC Encapsulation
| SFC |
+---------+ +----------------+ Encapsulation +---------+
|SFC-Aware|-----------------+ \ +------------|SFC Proxy|
| SF | ... ----------+ \ \ / +---------+
+---------+ \ \ \ /
+-------+--------+
| SF Forwarder |
| (SFF) |
+-------+--------+
|
SFC Encapsulation
|
... SFC-enabled Domain ...
|
Network Overlay Transport
|
_,....._
,-' `-.
/ `.
| Network |
`. /
`.__ __,-'
`''''
Figure 3: SFC Architecture Components After Initial Classification
図3：初期分類後のSFCアーキテクチャコンポーネント
Please note that the depiction in Figure 3 shows packets after initial classification, and therefore includes the SFC encapsulation. Although not included in Figure 3, the classifier is an SFC architectural component.
図3の描写は、最初の分類後のパケットを示しているため、SFCカプセル化が含まれていることに注意してください。図3には含まれていませんが、分類子はSFCアーキテクチャコンポーネントです。
The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required.
SFCカプセル化により、サービス機能パスの選択が可能になります。また、メタデータの交換が必要な場合に、メタデータ/コンテキスト情報を共有することもできます。
The SFC encapsulation carries explicit information used to identify the SFP. However, the SFC encapsulation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. If packets need to flow between separate physical platforms, the SFC encapsulation relies on an outer network transport. Transit forwarders -- such as router and switches -- forward SFC encapsulated packets based on the outer (non-SFC) encapsulation.
SFCカプセル化は、SFPを識別するために使用される明示的な情報を伝達します。ただし、SFCカプセル化自体はトランスポートカプセル化ではありません。ネットワークファブリック内でパケットを転送するためには使用されません。パケットが別々の物理プラットフォーム間を流れる必要がある場合、SFCカプセル化は外部ネットワークトランスポートに依存します。ルーターやスイッチなどの中継フォワーダーは、外部（非SFC）カプセル化に基づいてSFCカプセル化パケットを転送します。
One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such, any network transport protocol may be used to carry the SFC encapsulated traffic.
SFCの主要なアーキテクチャ原則の1つは、SFCカプセル化がトランスポートに依存しないことです。そのため、SFCカプセル化トラフィックを伝送するために、任意のネットワーク転送プロトコルを使用できます。
The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation.
SFの概念は進化します。 SFは、ネットワーク内のバンプと見なされるのではなく、指定された管理ドメイン内のリソースになり、複合サービスの一部として使用できるようになります。 SFは1つ以上のSFFとの間でデータを送受信します。 SFC対応のSFは、SFCカプセル化でこのトラフィックを受信します。
While the SFC architecture defines the concept and specifies some characteristics of a new encapsulation -- the SFC encapsulation -- and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6). The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section.
SFCアーキテクチャは概念を定義し、新しいカプセル化のいくつかの特性-SFCカプセル化-およびSFCを構築するためのいくつかの論理コンポーネントを指定しますが、既存のSF実装は、新しいSFCに作用する機能または完全に統合する機能を持たない場合がありますカプセル化。このようなSFがアーキテクチャに参加するためのメカニズムを提供するために、SFCプロキシ機能が定義されています（セクション4.6を参照）。 SFCプロキシは、SFCカプセル化とSFC非対応SF間のゲートウェイとして機能します。 SFC非対応サービス機能の統合については、SFCプロキシセクションで詳しく説明します。
This architecture allows an SF to be part of multiple SFPs and SFCs.
このアーキテクチャにより、SFを複数のSFPおよびSFCの一部にすることができます。
The SFF is responsible for forwarding packets and/or frames received from the network to one or more SFs associated with a given SFF using information conveyed in the SFC encapsulation. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. Some SFs, such as firewalls, could also consume a packet.
SFFは、ネットワークから受信したパケットやフレームを、SFCカプセル化で伝達された情報を使用して、特定のSFFに関連付けられた1つ以上のSFに転送します。 SFからのトラフィックは、最終的に同じSFFに戻ります。SFFは、トラフィックをネットワークに注入します。ファイアウォールなどの一部のSFもパケットを消費する可能性があります。
The collection of SFFs and associated SFs creates a service-plane overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this service plane, the SFF component connects different SFs that form a service function path.
SFFと関連するSFのコレクションは、SFC対応のSFとSFC非対応のSFが存在するサービスプレーンオーバーレイを作成します。このサービスプレーン内で、SFFコンポーネントは、サービス機能パスを形成するさまざまなSFを接続します。
SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed by the constraints of the SFP.
SFFは必要なSFP転送情報を維持します。 SFP転送情報は、SFPを一意に識別するために使用されるサービスパス識別子に関連付けられています。サービスフォワーディングステートにより、SFFは、特定のSFPのどのSFをどの順序で適用する必要があるかを、トラフィックが関連するSFPを通過するときに識別できます。 SFFからは特定のSFを配信するための唯一の利用可能な方法であるように見えますが、SFPの制約によって複数の選択肢が許可されている場合もあります。
If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the SF may well be stateful. Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification.
複数の選択肢がある場合、SFはステートフルである可能性が高いため、SFFは、特定のフローのすべてのパケットが同じ方法で処理されるという特性を維持する必要があります。さらに、SFFは、サブスクライバー、セッション、またはアプリケーションインスタンスの識別など、フローの他のプロパティに基づいてパケットの処理を保持する場合があります。
The SFF also has the information that allows it to forward packets to the next SFF after applying local service functions. Again, while there may be only a single choice available, the architecture allows for multiple choices for the next SFF. As with SFs, the solution needs to operate such that the behavior with regard to specific flows (see the Rendered Service Path) is stable. The selection of available SFs and next SFFs may be interwoven when an SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what is allowed in these cases.
SFFには、ローカルサービス機能の適用後にパケットを次のSFFに転送できるようにする情報もあります。繰り返しになりますが、利用可能な選択肢は1つしかないかもしれませんが、このアーキテクチャでは、次のSFFに複数の選択肢を用意しています。 SFと同様に、ソリューションは、特定のフロー（レンダリングされたサービスパスを参照）に関する動作が安定するように動作する必要があります。 SFFが複数の異なるサービス機能をサポートし、同じサービス機能が複数のSFFで利用可能な場合、使用可能なSFと次のSFFの選択が織り交ぜられる場合があります。ソリューションでは、これらのケースで何が許可されているかを明確にする必要があります。
Even when the SFF supports and utilizes multiple choices, the decision as to whether to use flow-specific mechanisms or coarser-grained means to ensure that the behavior of specific flows is stable is a matter for specific solutions and specific implementations.
SFFが複数の選択肢をサポートおよび利用している場合でも、特定のフローの動作が安定していることを保証するためにフロー固有のメカニズムを使用するか、より粗い手段を使用するかについての決定は、特定のソリューションおよび特定の実装の問題です。
The SFF component has the following primary responsibilities:
SFFコンポーネントには、主に次の役割があります。
1. SFP forwarding: Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. After SF processing, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non-local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata.
1. SFP転送：トラフィックはネットワークからSFFに到着します。 SFFは、SFCカプセル化に含まれる情報を介してトラフィックが転送される適切なSFを決定します。 SF処理後、トラフィックはSFFに返され、必要に応じて、そのSFFに関連付けられた別のSFに転送されます。 SFPに別の非ローカル（つまり、異なるSFF）ホップがある場合、SFFはトラフィックを適切なネットワークトランスポートプロトコルにさらにカプセル化し、パスに沿って次のSFFに配信するためにネットワークに配信します。この転送責任に関連して、SFFはメタデータと対話できる必要があります。
2. Terminating SFPs: An SFC is completely executed when traffic has traversed all required SFs in a chain. When traffic arrives at the SFF after the last SF has finished processing it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and delivers the packet back to the network for forwarding.
2. 終端SFP：トラフィックがチェーン内の必要なすべてのSFを通過すると、SFCは完全に実行されます。最後のSFが処理を完了した後にトラフィックがSFFに到着すると、最後のSFFはサービス転送状態からSFCが完了したことを認識します。 SFFはSFCカプセル化を削除し、パケットを転送するためにネットワークに送り返します。
3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. This state information may be used for a range of SFP-related tasks such as ensuring consistent treatment of all packets in a given flow, ensuring symmetry, or for state-aware SFC Proxy functionality (see Section 4.8).
3. フロー状態の維持：場合によっては、SFFがステートフルになることがあります。フローを作成し、フロー中心の情報を保存します。この状態情報は、特定のフロー内のすべてのパケットの一貫した処理の保証、対称性の保証、または状態認識SFCプロキシ機能（セクション4.8を参照）など、SFP関連のさまざまなタスクに使用できます。
SFP forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information, if it can be arranged, to provide explicit service path information.
上記のように、SFP転送は、SFCカプセル化に含まれるサービスパス情報の使用に直接依存します。ただし、既存の実装ではSFCカプセル化を実行できない場合があります。これらのプラットフォームは、アレンジできる場合は、既存のトランスポート情報を使用して、明示的なサービスパス情報を提供することを選択できます。
This results in the same architectural behavior and meaning for SFP forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation.
これにより、SFP転送およびサービス機能パスのアーキテクチャ動作と意味は同じになります。このような場合に実行されるトランスポートパスが、サービスチェーンカプセル化の情報によって識別されるパスと完全に一致するようにするのは、制御コンポーネントの責任です。
Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information. Using the term "node" to refer generically to an entity that is performing a set of functions, in this context, an SFC boundary node denotes a node that connects one SFC-enabled domain to a node either located in another SFC-enabled domain or in a domain that is SFC-unaware.
たとえば、SFC情報の漏洩を回避するために、SFC対応ドメインの境界で特定の機能を適用する必要がある場合があります。 「ノード」という用語を使用して、一連の機能を実行しているエンティティを総称します。このコンテキストでは、SFC境界ノードは、1つのSFC対応ドメインを、別のSFC対応ドメインにあるノードまたはSFC非対応のドメイン内。
An SFC boundary node can act as egress or ingress. An SFC Egress Node denotes an SFC boundary node that handles traffic leaving the SFC-enabled domain the Egress Node belongs to. Such a node is required to remove any information specific to the SFC Domain, typically the SFC encapsulation. Further, from a privacy perspective, an SFC Egress Node is required to ensure that any sensitive information added as part of SFC gets removed. In this context, information may be sensitive due to network concerns or end-customer concerns. An SFC Ingress Node denotes an SFC boundary node that handles traffic entering the SFC-enabled domain. In most solutions and deployments this will need to include a classifier, and will be responsible for adding the SFC encapsulation to the packet.
SFC境界ノードは、出力または入力として機能できます。 SFC出力ノードは、出力ノードが属するSFC対応ドメインを出るトラフィックを処理するSFC境界ノードを示します。このようなノードは、SFCドメイン固有の情報、通常はSFCカプセル化を削除するために必要です。さらに、プライバシーの観点から、SFCの一部として追加された機密情報が確実に削除されるように、SFC出力ノードが必要です。このような状況では、ネットワークの問題やエンドユーザーの問題により、情報が機密になる可能性があります。 SFC入力ノードは、SFC対応ドメインに入るトラフィックを処理するSFC境界ノードを示します。ほとんどのソリューションと展開では、これに分類子を含める必要があり、パケットにSFCカプセル化を追加する必要があります。
An SFC Proxy and corresponding SFC-unaware service function (see Figure 3) are inside the SFC-enabled domain.
SFCプロキシと対応するSFC非対応サービス機能（図3を参照）は、SFC対応ドメイン内にあります。
Underneath the SFF there are components responsible for performing the transport (overlay) forwarding. They do not consult the SFC encapsulation or inner payload for performing this forwarding. They only consult the outer-transport encapsulation for the transport (overlay) forwarding.
SFFの下には、トランスポート（オーバーレイ）転送を実行するコンポーネントがあります。この転送を実行するために、SFCカプセル化または内部ペイロードを調べません。トランスポート（オーバーレイ）転送については、外部トランスポートカプセル化のみを調べます。
In order for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions) a logical SFC proxy function may be used. This function sits between an SFF and one or more SFs to which the SFF is directing traffic (see Figure 3).
SFCアーキテクチャがSFC非対応のSF（レガシーサービス機能など）をサポートするために、論理SFCプロキシ機能を使用できます。この機能は、SFFと、SFFがトラフィックを送信する1つ以上のSFの間に位置します（図3を参照）。
The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC-unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path.
プロキシは、SFに代わってSFFからのパケットを受け入れます。 SFCカプセル化を削除し、ローカル接続回路を使用してSFC非対応SFにパケットを配信します。また、SFからパケットを受信し、SFCカプセル化を再適用し、サービス機能パスに沿って処理するためにSFFに戻します。
Thus, from the point of view of the SFF, the SFC proxy appears to be part of an SFC-aware SF.
したがって、SFFの観点からは、SFCプロキシはSFC対応のSFの一部であるように見えます。
Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC-aware SF. The details of that are not part of this architecture. The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF are dependent upon the specific behaviors and capabilities of that SFC-unaware SF, and thus are also out of scope for this architecture.
SFFとSFCプロキシ間の通信の詳細は、SFFとSFC対応のSF間の通信の詳細と同じです。その詳細はこのアーキテクチャの一部ではありません。 SFCプロキシとSFC非対応SF間のローカル接続回線を介した通信方法の詳細は、そのSFC非対応SFの特定の動作と機能に依存するため、このアーキテクチャの範囲外です。
Specifically, for traffic received from the SFF intended for the SF the proxy is representing, the SFC proxy:
具体的には、プロキシが表すSF向けのSFFから受信したトラフィックの場合、SFCプロキシは次のようになります。
o Removes the SFC encapsulation from SFC encapsulated packets.
o SFCカプセル化パケットからSFCカプセル化を削除します。
o Identifies the required SF to be applied based on available information including that carried in the SFC encapsulation.
o SFCカプセル化で運ばれるものを含む利用可能な情報に基づいて、適用される必要なSFを識別します。
o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, Layer 2 Tunneling Protocol version 3 (L2TPv3), Generic Routing Encapsulation (GRE), and Virtual eXtensible Local Area Network (VXLAN).
oこのSFPの次のSFが到達可能な適切なアウトバウンドローカル接続回線を選択します。これは、SFCカプセル化で運ばれるSFの識別から導き出され、ローカル技術を含む場合があります。ローカル接続回線の例には、VLAN、IP-in-IP、レイヤー2トンネリングプロトコルバージョン3（L2TPv3）、Generic Routing Encapsulation（GRE）、およびVirtual eXtensible Local Area Network（VXLAN）が含まれますが、これらに限定されません。
o Forwards the original payload via the selected local attachment circuit to the appropriate SF.
o 選択したローカル接続回線を介して元のペイロードを適切なSFに転送します。
When traffic is returned from the SF:
SFからトラフィックが返される場合：
o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to reapply the correct SFC encapsulation.
o 必要なSFCカプセル化を適用します。カプセル化の詳細の決定は、パケットおよび/またはフレームが受信されたローカル接続回路によって、またはパケット分類または他のローカルポリシーを介して推論されます。場合によっては、SFによるパケットの順序付けまたは変更により、正しいSFCカプセル化を再適用するために追加の分類が必要になることがあります。
o Delivers the packet with the SFC encapsulation to the SFF, as would happen with packets returned from an SFC-aware SF.
o SFC対応のSFから返されたパケットと同様に、SFCカプセル化を使用してパケットをSFFに配信します。
Traffic from the network that satisfies classification criteria is directed into an SFP and forwarded to the requisite service function(s). Classification is handled by a service classification function; initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier and the requirements of the SFC policy. For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A, or quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B.
分類基準を満たすネットワークからのトラフィックは、SFPに送信され、必要なサービス機能に転送されます。分類は、サービス分類関数によって処理されます。初期分類は、SFCドメインへの入口で行われます。初期分類の粒度は、分類子の機能とSFCポリシーの要件によって決まります。たとえば、分類は比較的粗い場合があります。このポートからのすべてのパケットはSFCポリシーXの対象となり、SFP Aに送信されます。または非常に細かい：この5タプルに一致するすべてのパケットは、SFCポリシーYの対象となり、SFP Bに送信されます。
As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created. Classification results in attaching the traffic to a specific SFP.
分類の決定の結果として、適切なSFCカプセル化がデータに課され、適切なSFPが選択または作成されます。分類により、トラフィックが特定のSFPに接続されます。
The SFC architecture supports reclassification (or non-initial classification) as well. As packets traverse an SFP, reclassification may occur -- typically performed by a classification function co-resident with a service function. Reclassification may result in the selection of a new SFP, an update of the associated metadata, or both. This is referred to as "branching".
SFCアーキテクチャは、再分類（または非初期分類）もサポートしています。パケットがSFPを通過するときに、再分類が行われる可能性があります-通常、サービス機能と共存する分類機能によって実行されます。再分類により、新しいSFPの選択、関連するメタデータの更新、またはその両方が行われる場合があります。これは「分岐」と呼ばれます。
For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. However, when the DPI service function is executed, attack traffic is detected at the application layer. DPI_1 reclassifies the traffic as attack and alters the service path to SFP B, to include a firewall for policy enforcement: dropping the traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would be returned to the original SFF. In this simple example, the DPI service function reclassifies the traffic based on local application layer classification capabilities (that were not available during the initial classification step).
たとえば、最初の分類では、SFP A：DPI_1-> SLB_8が選択されます。ただし、DPIサービス機能が実行されると、アプリケーション層で攻撃トラフィックが検出されます。 DPI_1は、トラフィックを攻撃として再分類し、SFP Bへのサービスパスを変更して、ポリシーを実施するためのファイアウォールを含めます。トラフィックのドロップ：DPI_1-> FW_4。 FW_4以降、残っているトラフィックは元のSFFに戻ります。この単純な例では、DPIサービス機能は、ローカルアプリケーションレイヤー分類機能（最初の分類手順では利用できなかった機能）に基づいてトラフィックを再分類します。
When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform reclassification of traffic to determine the SFP. The SFC Proxy is concerned with re-attaching information for SFC-unaware SFs, and a stateful SFC Proxy simplifies such classification to a flow lookup.
SFC非対応のSFを経由してトラフィックが到着すると、SFCプロキシはトラフィックの再分類を実行して、SFPを決定する必要があります。 SFCプロキシはSFC非対応SFの情報の再アタッチに関係し、ステートフルSFCプロキシはそのような分類をフロールックアップに簡素化します。
Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange, and the sharing of service-derived information to the network. Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture:
メタデータを共有することにより、ネットワークはSFへのネットワーク派生情報の提供、SFからSFへの情報交換、およびサービス派生情報のネットワークへの共有を可能にします。一部のSFCはメタデータ交換を必要としない場合があります。 SFCインフラストラクチャは、SFPに沿ったこの共有データの交換を可能にします。共有メタデータは、SFCアーキテクチャ内でいくつかの可能な役割を果たします。
o Allows elements that typically operate independently (e.g., as "ships in the night") to exchange information.
o 通常は独立して動作する要素（「夜の船」など）が情報を交換できるようにします。
o Encodes information about the network and/or data for subsequent use within the SFP.
o SFP内で後で使用するために、ネットワークやデータに関する情報をエンコードします。
o Creates an identifier used for policy binding by SFs.
o SFによるポリシーバインディングに使用される識別子を作成します。
Context information can be derived in several ways:
コンテキスト情報は、いくつかの方法で導出できます。
o External sources
o 外部ソース
o Network node classification
o ねとぉｒｋ ので ｃぁっしふぃかちおん
o Service function classification
o サービス機能分類
There are a number of issues that solutions need to address, and that the architecture informs but does not determine. This section lays out some of those concepts.
ソリューションが対処する必要がある多くの問題があり、アーキテクチャは通知しますが決定しません。このセクションでは、それらの概念のいくつかを説明します。
Much of the behavior of service chains is driven by operator and per-customer policy. This architecture is structured to isolate the policy interactions from the data plane and control logic.
サービスチェーンの動作の多くは、オペレーターおよび顧客ごとのポリシーによって決まります。このアーキテクチャは、データプレーンおよび制御ロジックからポリシーの相互作用を分離するように構造化されています。
Specifically, it is assumed that the service chaining control plane creates the service paths. The service chaining data plane is used to deliver the classified packets along the service chains to the intended service functions.
具体的には、サービスチェーンコントロールプレーンがサービスパスを作成すると想定されています。サービスチェーンデータプレーンは、分類されたパケットをサービスチェーンに沿って目的のサービス機能に配信するために使用されます。
Policy, in contrast, interacts with the system in other places. Policies and policy engines may monitor service functions to decide if additional (or fewer) instances of services are needed. When applicable, those decisions may in turn result in interactions that direct the control logic to change the SFP placement or packet classification rules.
対照的に、ポリシーは他の場所にあるシステムと相互作用します。ポリシーおよびポリシーエンジンは、サービス機能を監視して、サービスの追加（またはより少ない）インスタンスが必要かどうかを判断します。該当する場合、これらの決定により、SFP配置またはパケット分類ルールを変更するように制御ロジックに指示する相互作用が発生する可能性があります。
Similarly, operator service policy, often managed by Operations or Business Support Systems (OSS or BSS), will frequently determine what service functions are available. Operator service policies also determine which sequences of functions are valid and are to be used or made available.
同様に、オペレーターサービスポリシーは、オペレーションまたはビジネスサポートシステム（OSSまたはBSS）によって管理されることが多く、利用可能なサービス機能を頻繁に決定します。オペレーターサービスポリシーは、どの機能シーケンスが有効であり、使用または使用可能にするかを決定します。
The offering of service chains to customers, and the selection of which service chain a customer wishes to use, are driven by a combination of operator and customer policies using appropriate portals in conjunction with the OSS and BSS tools. These selections then drive the service chaining control logic, which in turn establishes the appropriate packet classification rules.
顧客へのサービスチェーンの提供、および顧客が使用したいサービスチェーンの選択は、OSSおよびBSSツールと組み合わせて適切なポータルを使用するオペレーターと顧客のポリシーの組み合わせによって決まります。これらの選択により、サービスチェーン制御ロジックが駆動され、次に、適切なパケット分類ルールが確立されます。
The SFC control plane is part of the overall SFC architecture, and this section describes its high-level functions. However, the detailed definition of the SFC control plane is outside the scope of this document.
SFCコントロールプレーンは、SFCアーキテクチャ全体の一部であり、このセクションでは、その高度な機能について説明します。ただし、SFCコントロールプレーンの詳細な定義は、このドキュメントの範囲外です。
The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths, and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay. For instance, an SFC construction may be static; selecting exactly which SFFs and which SFs from those SFFs are to be used, or it may be dynamic, allowing the network to perform some or all of the choices of SFF or SF to use to deliver the selected service chain within the constraints represented by the service path.
SFCコントロールプレーンは、SFPを構築し、SFCを転送パスに変換し、パス情報を参加ノードに伝達して、サービスオーバーレイを構築するために必要な転送動作を実現します。たとえば、SFCの構造は静的な場合があります。使用するSFFとそのSFFからのSFを正確に選択するか、動的にすることもできます。これにより、ネットワークは、SFFまたはSFの選択の一部またはすべてを実行して、サービスパス。
In the SFC architecture, SFs are resources; the control plane manages and communicates their capabilities, availability, and location in fashions suitable for the transport and SFC operations in use. The control plane is also responsible for the creation of the context (see below). The control plane may be distributed (using new or existing control-plane protocols), or be centralized, or a combination of the two.
SFCアーキテクチャでは、SFはリソースです。コントロールプレーンは、使用中のトランスポートおよびSFC操作に適した方法で、それらの機能、可用性、および場所を管理および通信します。コントロールプレーンは、コンテキストの作成も担当します（以下を参照）。コントロールプレーンは、分散する（新しいまたは既存のコントロールプレーンプロトコルを使用する）か、集中化するか、またはこの2つの組み合わせです。
The SFC control plane provides the following functionality:
SFCコントロールプレーンは、次の機能を提供します。
1. An SFC-enabled domain wide view of all available service function resources as well as the network locators through which they are reachable.
1. 使用可能なすべてのサービス機能リソースと、それらが到達可能なネットワークロケーターのSFC対応ドメイン全体のビュー。
2. Uses SFC policy to construct service function chains, and associated SFPs.
2. SFCポリシーを使用して、サービス機能チェーンおよび関連するSFPを構築します。
3. Selection of specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the time of delivering traffic to them).
3. 要求されたSFCの特定のSFの選択。静的（特定のSFを使用）または動的（サービスへのトラフィックの配信時にサービスの明示的SFを使用）。
4. Provides requisite SFC data-plane information to the SFC architecture components, most notably the SFF.
4. SFCアーキテクチャコンポーネント、特にSFFに必要なSFCデータプレーン情報を提供します。
5. Provides the metadata and usage information classifiers need so that they in turn can provide this metadata for appropriate packets in the data plane.
5. 分類子が必要とするメタデータおよび使用情報を提供し、データプレーンの適切なパケットにこのメタデータを提供できるようにします。
6. When needed, provide information including policy information to other SFC elements to be able to properly interpret metadata.
6. 必要に応じて、メタデータを適切に解釈できるように、ポリシー情報を含む情報を他のSFC要素に提供します。
The SFC system may be responsible for managing all resources necessary for the SFC components to function. This includes network constraints used to plan and choose network path(s) between service function forwarders, network communication paths between service function forwarders and their attached service functions, characteristics of the nodes themselves such as memory, number of virtual interfaces, routes, and instantiation, configuration, and deletion of SFs.
SFCシステムは、SFCコンポーネントが機能するために必要なすべてのリソースを管理する責任があります。これには、サービス機能フォワーダー間のネットワークパスの計画と選択に使用されるネットワーク制約、サービス機能フォワーダーとそれに接続されたサービス機能間のネットワーク通信パス、メモリなどのノード自体の特性、仮想インターフェイスの数、ルート、インスタンス化が含まれます、構成、およびSFの削除。
The SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system.
SFCシステムは、システム内の他のコンポーネントによって表されるように、リソース制御に関するポリシー決定を反映することも必要になります。
While all of these aspects are part of the overall system, they are beyond the scope of this architecture.
これらの側面はすべてシステム全体の一部ですが、このアーキテクチャの範囲を超えています。
This SFC architecture is predicated on topological independence from the underlying forwarding topology. Consequently, a service topology is created by service function paths or by the local decisions of the service function forwarders based on the constraints expressed in the SFP. Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once. The Service Chaining solution needs to permit these limited and policy-compliant loops. At the same time, the solutions must ensure that indefinite and unbounded loops cannot be formed, as such would consume unbounded resources without delivering any value.
このSFCアーキテクチャは、基盤となる転送トポロジーからのトポロジーの独立性を前提としています。その結果、サービストポロジは、サービス機能パスによって、またはSFPで表現された制約に基づくサービス機能フォワーダーのローカル決定によって作成されます。オーバーレイの制約により、パケット転送パスは同じSFFに複数回アクセスする必要がある場合があり、まれに、同じSFに複数回アクセスする必要がある場合もあります。サービスチェーンソリューションは、これらの制限されたポリシーに準拠したループを許可する必要があります。同時に、ソリューションは、無限の無限ループが形成されないようにする必要があります。無限ループは、値を提供せずに無限リソースを消費するためです。
In other words, this architecture requires the solution to prevent infinite service function loops, even when service functions may be invoked multiple times in the same SFP.
つまり、このアーキテクチャでは、同じSFPでサービス関数が複数回呼び出される場合でも、無限のサービス関数ループを防ぐソリューションが必要です。
Supporting function elasticity and high-availability should not overly complicate SFC or lead to unnecessary scalability problems.
サポート機能の弾力性と高可用性は、SFCを過度に複雑にしたり、不必要なスケーラビリティの問題を引き起こしたりしてはなりません。
In the simplest case, where there is only a single function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC.
SFPに単一の機能しかない（ネクストホップがフローの宛先アドレスまたはその宛先への適切なネクストホップのいずれかである）最も単純なケースでは、SFCは必要ないと主張することができます。
In the cases where the classifier is separate from the single function or a function at the terminal address may need a sub-prefix (e.g., finer-grained address information) or per-subscriber metadata, a single SFP exists (i.e., the metadata changes but the SFP does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4.
分類子が単一の関数から分離している場合、または端末アドレスの関数がサブプレフィックス（たとえば、より細かいアドレス情報）またはサブスクライバーごとのメタデータを必要とする場合、単一のSFPが存在します（つまり、メタデータの変更ただし、フローの潜在的な端末アドレスの数に関係なく、SFPはそうではありません。これは、単純なロードバランサーの場合です。図4を参照してください。
+---+ +---++--->web server
source+-->|sff|+-->|sf1|+--->web server
+---+ +---++--->web server
Figure 4: Simple Load Balancing
図4：単純な負荷分散
By extrapolation, in the case where intermediary functions within a chain had similar "elastic" behaviors, we do not need separate chains to account for this behavior -- as long as the traffic coalesces to a common next-hop after the point of elasticity.
外挿により、チェーン内の中間機能に同様の「弾性」動作があった場合、トラフィックが弾性ポイントの後で共通のネクストホップに合体する限り、この動作を説明するために個別のチェーンは必要ありません。
In Figure 5, we have a chain of five service functions between the traffic source and its destination.
図5では、トラフィックソースとその宛先の間に5つのサービス機能のチェーンがあります。
+---+ +---+ +---+ +---+ +---+ +---+
|sf2| |sf2| |sf3| |sf3| |sf4| |sf4|
+---+ +---+ +---+ +---+ +---+ +---+
| | | | | |
+-----+-----+ +-----+-----+
| |
+ +
+---+ +---+ +---+ +---+ +---+
source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
+---+ +---+ +---+ +---+ +---+
+ + +
| | |
+---+ +---+ +---+
|sf1| |sf3| |sf5|
+---+ +---+ +---+
Figure 5: Load Balancing
図5：負荷分散
This would be represented as one service function path: sf1 -> sf2 -> sf3 -> sf4 -> sf5. The SFF is a logical element, which may be made up of one or multiple components. In this architecture, the SFF may handle load distribution based on policy.
これは、1つのサービス関数パスとして表されます：sf1-> sf2-> sf3-> sf4-> sf5。 SFFは論理要素であり、1つまたは複数のコンポーネントで構成されます。このアーキテクチャでは、SFFはポリシーに基づいて負荷分散を処理します。
It can also be seen in the above that the same service function may be reachable through multiple SFFs, as discussed earlier. The selection of which SFF to use to reach sf3 may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints. In the latter case, it needs to be assured that exactly one SFF takes responsibility to steer traffic through sf3.
上記で説明したように、同じサービス機能が複数のSFFを介して到達可能である場合もあります。 sf3に到達するために使用するSFFの選択は、SFPを定義する際の制御ロジックによって行われるか、またはポリシー、ソリューション、および展開の制約に応じてSFF自体に任されます。後者の場合、1つのSFFがsf3を介してトラフィックを誘導する責任を負うことを保証する必要があります。
This architecture prescribes that additional information be added to packets to identify service function paths and often to represent metadata. It also envisions adding transport information to carry packets along service function paths, at least between service function forwarders. This added information increases the size of the packet to be carried by service chaining. Such additions could potentially increase the packet size beyond the MTU supported on some or all of the media used in the service chaining domain.
このアーキテクチャでは、サービス機能パスを識別し、多くの場合メタデータを表すために、パケットに追加情報を追加することが規定されています。また、少なくともサービス機能フォワーダー間で、サービス機能パスに沿ってパケットを運ぶためのトランスポート情報を追加することも想定しています。この追加された情報により、サービスチェーンによって伝送されるパケットのサイズが増加します。このような追加により、サービスチェーンドメインで使用される一部またはすべてのメディアでサポートされるMTUを超えてパケットサイズが増加する可能性があります。
Such packet size increases can thus cause operational MTU problems. Requiring fragmentation and reassembly in an SFF would be a major processing increase and might be impossible with some transports. Expecting service functions to deal with packets fragmented by the SFC function might be onerous even when such fragmentation was possible. Thus, at the very least, solutions need to pay attention to the size cost of their approach. There may be alternative or additional means available, although any solution needs to consider the trade-offs.
したがって、このようなパケットサイズの増加は、MTUの動作に問題を引き起こす可能性があります。 SFFで断片化と再構成が必要になると、処理が大幅に増加し、一部のトランスポートでは不可能になる場合があります。 SFC機能によって断片化されたパケットを処理するサービス機能を期待することは、そのような断片化が可能であったとしても煩わしいかもしれません。したがって、少なくとも、ソリューションはアプローチのサイズコストに注意を払う必要があります。解決策にはトレードオフを考慮する必要がありますが、代替または追加の手段が利用できる場合があります。
These considerations apply to any generic architecture that increases the header size. There are also more specific MTU considerations: Effects on Path MTU Discovery (PMTUD) as well as deployment considerations. Deployments within a single administrative control or even a single data center complex can afford more flexibility in dealing with larger packets, and deploying existing mitigations that decrease the likelihood of fragmentation or discard.
これらの考慮事項は、ヘッダーサイズを増やす一般的なアーキテクチャに適用されます。また、より具体的なMTUの考慮事項があります。パスMTUディスカバリー（PMTUD）への影響と、配置の考慮事項です。単一の管理コントロールまたは単一のデータセンター複合システム内での展開では、より大きなパケットを処理し、断片化または破棄の可能性を減らす既存の軽減策を展開する際に、より高い柔軟性を提供できます。
Operations, Administration, and Maintenance (OAM) tools are an integral part of the architecture. These serve various purposes, including fault detection and isolation, and performance management. For example, there are many advantages of SFP liveness detection, including status reporting, support for resiliency operations and policies, and an enhanced ability to balance load.
運用、管理、および保守（OAM）ツールは、アーキテクチャの不可欠な部分です。これらは、障害の検出と分離、パフォーマンス管理など、さまざまな目的に役立ちます。たとえば、SFPの活性検出には、ステータスレポート、復元操作とポリシーのサポート、負荷分散機能の強化など、多くの利点があります。
Service function paths create a services topology, and OAM performs various functions within this service layer. Furthermore, SFC OAM follows the same architectural principles of SFC in general. For example, topological independence (including the ability to run OAM over various overlay technologies) and classification-based policy.
サービス機能パスはサービストポロジを作成し、OAMはこのサービスレイヤー内でさまざまな機能を実行します。さらに、SFC OAMは一般にSFCと同じアーキテクチャの原則に従います。たとえば、トポロジーの独立性（さまざまなオーバーレイテクノロジーでOAMを実行する機能を含む）や分類ベースのポリシー。
We can subdivide the SFC OAM architecture in two parts:
SFC OAMアーキテクチャを2つの部分に分割できます。
o In-band: OAM packets follow the same path and share fate with user packets, within the service topology. For this, they also follow the architectural principle of consistent policy identifiers, and use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are particularly important here.
o インバンド：OAMパケットは同じパスをたどり、サービストポロジ内でユーザーパケットと運命を共有します。このため、それらは一貫したポリシー識別子のアーキテクチャ原理にも従い、サービスチェーンデータパケットと同じパスIDを使用します。ここでは、パケット転送による負荷分散とSFCカプセル化が特に重要です。
o Out-of-band: Reporting beyond the actual data plane. An additional layer beyond the data-plane OAM allows for additional alerting and measurements.
o 帯域外：実際のデータプレーンを超えたレポート。データプレーンOAMを超えた追加のレイヤーにより、追加のアラートと測定が可能になります。
This architecture prescribes end-to-end SFP OAM functions, which implies SFF understanding of whether an in-band packet is an OAM or user packet. However, service function validation is outside of the scope of this architecture, and application-level OAM is not what this architecture prescribes.
このアーキテクチャは、エンドツーエンドのSFP OAM機能を規定しています。これは、インバンドパケットがOAMパケットであるかユーザーパケットであるかをSFFが理解していることを意味します。ただし、サービス機能の検証はこのアーキテクチャの範囲外であり、アプリケーションレベルのOAMはこのアーキテクチャで規定されているものではありません。
Some of the detailed functions performed by SFC OAM include fault detection and isolation in a service function path or a service function, verification that connectivity using SFPs is both effective and directing packets to the intended service functions, service path tracing, diagnostic and fault isolation, alarm reporting, performance measurement, locking and testing of service functions, validation with the control plane (see Section 5.2), and also allow for vendor-specific as well as experimental functions. SFC should leverage and, if needed, extend relevant existing OAM mechanisms.
SFC OAMによって実行される詳細な機能には、サービス機能パスまたはサービス機能での障害検出と分離、SFPを使用した接続が効果的であることの確認、および目的のサービス機能へのパケットの送信、サービスパストレース、診断と障害分離の両方が含まれます。アラームレポート、パフォーマンス測定、サービス機能のロックとテスト、コントロールプレーンによる検証（セクション5.2を参照）。ベンダー固有の機能や実験機能も可能です。 SFCは、関連する既存のOAMメカニズムを活用し、必要に応じて拡張する必要があります。
As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These may be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state (as, for example, stateful-firewall state) is the responsibility of the SF, and not addressed by this architecture.
実際の運用要件として、サービスチェーンソリューションは、障害状態に効果的かつ通常は非常に迅速に対応できる必要があります。これらは、SFF間のネットワークの接続の障害、SFFの障害、またはSFの障害である可能性があります。 SFごとの状態（たとえば、ステートフルファイアウォールの状態）はSFの責任であり、このアーキテクチャでは対処されません。
Multiple techniques are available to address this issue. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this. Solutions can also make use of MAC- or IP-level redundancy mechanisms such as Virtual Router Redundancy Protocol (VRRP). Also, particularly for SF failures, load balancers co-located with the SFF or as part of the service function delivery mechanism can provide such robustness.
この問題に対処するために複数の手法が利用できます。ソリューションは、障害に対処するために必要なものと許可するものの両方を説明できます。 SFFがタイムリーに十分な情報を提供できる場合、ソリューションはサービス機能パスの柔軟な特定性を利用できます。ソリューションでは、仮想ルーター冗長プロトコル（VRRP）などのMACレベルまたはIPレベルの冗長メカニズムを利用することもできます。また、特にSF障害の場合、SFFと同じ場所に配置された、またはサービス機能配信メカニズムの一部としてロードバランサーを使用すると、このような堅牢性を実現できます。
Similarly, operational requirements imply resilience in the face of load changes. While mechanisms for managing (e.g., monitoring, instantiating, loading images, providing configuration to SFC control, deleting, etc.) virtual machines are out of scope for this architecture, solutions can and are aided by describing how they can make use of scaling mechanisms.
同様に、運用要件は、負荷の変化に直面した場合の回復力を意味します。仮想マシンを管理するメカニズム（イメージの監視、インスタンス化、読み込み、SFC制御への構成の提供、削除など）はこのアーキテクチャの範囲外ですが、ソリューションはスケーリングメカニズムを利用する方法を説明することで支援できます。
The architecture described here is different from the current model, and moving to the new model could lead to different security arrangements and modeling. In the SFC architecture, a relatively static topologically-dependent deployment model is replaced with the chaining of sets of service functions. This can change the flow of data through the network, and the security and privacy considerations of the protocol and deployment will need to be reevaluated in light of the new model.
ここで説明するアーキテクチャは現在のモデルとは異なり、新しいモデルに移行すると、セキュリティの配置とモデリングが異なる可能性があります。 SFCアーキテクチャでは、比較的静的なトポロジに依存する展開モデルが、一連のサービス機能の連鎖で置き換えられます。これにより、ネットワークを介したデータのフローが変わる可能性があります。プロトコルと展開のセキュリティとプライバシーに関する考慮事項は、新しいモデルに照らして再評価する必要があります。
Security considerations apply to the realization of this architecture, in particular to the documents that will define protocols. Such realization ought to provide means to protect against security and privacy attacks in the areas hereby described.
セキュリティの考慮事項は、このアーキテクチャの実現、特にプロトコルを定義するドキュメントに適用されます。このような実現は、ここで説明されている領域でのセキュリティおよびプライバシー攻撃から保護する手段を提供する必要があります。
Building from the categorization of [RFC7498], we can largely divide the security considerations into four areas:
[RFC7498]の分類から構築すると、セキュリティに関する考慮事項を大きく4つの領域に分けることができます。
Service Overlay: Underneath the service function forwarders, the components that are responsible for performing the transport forwarding consult the outer-transport encapsulation for underlay forwarding. Used transport mechanisms should satisfy the security requirements of the specific SFC deployment. These requirements typically include varying degrees of traffic separation, protection against different attacks (e.g., spoofing, man-in-the-middle, brute-force, or insertion attacks), and can also include authenticity and integrity checking, and/or confidentiality provisions, for both the network overlay transport and traffic it encapsulates.
サービスオーバーレイ：サービス機能フォワーダーの下で、トランスポート転送の実行を担当するコンポーネントは、アンダーレイ転送の外部トランスポートカプセル化を調べます。使用されるトランスポートメカニズムは、特定のSFC展開のセキュリティ要件を満たす必要があります。これらの要件には通常、さまざまな程度のトラフィック分離、さまざまな攻撃（スプーフィング、中間者攻撃、ブルートフォース攻撃、挿入攻撃など）に対する保護が含まれ、認証と整合性チェック、および/または機密性のプロビジョニングも含まれる場合があります。 、ネットワークオーバーレイトランスポートとそれがカプセル化するトラフィックの両方。
Boundaries: Specific requirements may need to be enforced at the boundaries of an SFC-enabled domain. These include, for example, to avoid leaking SFC information, and to protect its borders against various forms of attacks. If untrusted parties can inject packets that will be treated as being properly classified for service chaining, there are a large range of attacks that can be mounted against the resulting system. Depending upon deployment details, these likely include spoofing packets from users and creating DDoS and reflection attacks of various kinds. Thus, when transport mechanisms are selected for use with SFC, they MUST ensure that outside parties cannot inject SFC packets that will be accepted for processing into the domain. This border security MUST include any tunnels to other domains. If those tunnels are to be used for SFC without reclassification, then the tunnel MUST include additional techniques to ensure the integrity and validity of such packets.
境界：SFC対応ドメインの境界で特定の要件を適用する必要がある場合があります。たとえば、SFC情報の漏洩を回避したり、さまざまな形の攻撃から国境を保護したりします。信頼できない当事者が、サービスチェーン用に適切に分類されたものとして扱われるパケットを注入できる場合、結果として生じるシステムに対して実行される可能性のある広範囲の攻撃があります。展開の詳細によっては、ユーザーからのパケットのなりすまし、さまざまな種類のDDoSおよびリフレクション攻撃の作成が含まれる可能性があります。したがって、SFCで使用するためにトランスポートメカニズムを選択する場合、外部メカニズムがドメインへの処理を受け入れるSFCパケットを注入できないようにする必要があります。この境界セキュリティには、他のドメインへのトンネルが含まれている必要があります。それらのトンネルが再分類なしでSFCに使用される場合、そのようなパケットの完全性と有効性を保証するために、トンネルは追加のテクニックを含まなければなりません（MUST）。
Classification: Classification is used at the ingress edge of an SFC-enabled domain. Policy for this classification is done using a plurality of methods. Whatever method is used needs to consider a range of security issues. These include appropriate authentication and authorization of classification policy, potential confidentiality issues of that policy, protection against corruption, and proper application of policy with needed segregation of application. This includes proper controls on the policies that drive the application of the SFC encapsulation and associated metadata to packets. Similar issues need to be addressed if classification is performed within a service chaining domain, i.e., reclassification.
分類：分類は、SFC対応ドメインの入口エッジで使用されます。この分類のポリシーは、複数の方法を使用して行われます。どの方法を使用する場合でも、さまざまなセキュリティ問題を考慮する必要があります。これらには、分類ポリシーの適切な認証と承認、そのポリシーの潜在的な機密性の問題、破損に対する保護、および必要なアプリケーションの分離を伴うポリシーの適切なアプリケーションが含まれます。これには、SFCカプセル化のアプリケーションと関連するメタデータをパケットに送るポリシーを適切に制御することが含まれます。分類がサービスチェーンドメイン内で実行される場合、つまり再分類の場合、同様の問題に対処する必要があります。
SFC Encapsulation: The SFC encapsulation provides at a minimum SFP identification, and carries metadata. An operator may consider the SFC Metadata as sensitive. From a privacy perspective, a user may be concerned about the operator revealing data about (and not belonging to) the customer. Therefore, solutions should consider whether there is a risk of sensitive information slipping out of the operator's control. Issues of information exposure should also consider flow analysis. Further, when a specific metadata element is defined, it should be carefully considered whether origin authentication is needed for it.
SFCカプセル化：SFCカプセル化は、最低限のSFP識別を提供し、メタデータを伝達します。オペレーターはSFCメタデータを機密と見なす場合があります。プライバシーの観点から、ユーザーはオペレーターが顧客に関する（そして顧客に属していない）データを公開することを懸念する場合があります。したがって、ソリューションでは、オペレーターの制御から機密情報が漏れるリスクがあるかどうかを検討する必要があります。情報公開の問題では、フロー分析も考慮する必要があります。さらに、特定のメタデータ要素を定義するときは、そのために発信元認証が必要かどうかを慎重に検討する必要があります。
A classifier may have privileged access to information about a packet or inside a packet (see Section 3, item 4, and Section 4.9) that is then communicated in the metadata. The threat of leaking this private data needs to be mitigated [RFC6973]. As one example, if private data is represented by an identifier, then a new identifier can be allocated, such that the mapping from the private data to the new identifier is not broadly shared.
分類子は、パケットに関する情報またはパケット内の情報（セクション3、アイテム4、およびセクション4.9を参照）への特権アクセスを持っている場合があり、メタデータで通信されます。この個人データの漏洩の脅威を軽減する必要があります[RFC6973]。一例として、プライベートデータが識別子によって表される場合、プライベートデータから新しい識別子へのマッピングが広く共有されないように、新しい識別子を割り当てることができます。
Some metadata added to and carried in SFC packets is sensitive for various reasons, including potentially revealing personally identifying information. Realizations of the architecture MUST protect such information to ensure that it is handled with suitable care and precautions against inappropriate dissemination. This can have implications to the data plane, the control plane, or both. Data-plane protocol definitions for SFC can include suitable provisions to protect such information for use when handling sensitive information, with packet or SFP granularity. Equally, the control mechanisms used with SFC can have provisions to determine that such mechanisms are available, and to ensure that they are used when needed. Inability to do so needs to result in error indications to appropriate management systems. In particular, when the control systems know that sensitive information may potentially be added to packets at certain points on certain service chains, the control mechanism MUST verify that appropriate protective treatment of NSH information is available from the point where the information is added to the point where it will be removed. If such mechanisms are unavailable, error notifications SHOULD be generated.
SFCパケットに追加されて運ばれる一部のメタデータは、個人を特定できる情報を明らかにするなど、さまざまな理由で機密性が高くなります。アーキテクチャの実現は、そのような情報を保護して、不適切な配布に対する適切な注意と予防策で処理されるようにする必要があります。これは、データプレーン、コントロールプレーン、またはその両方に影響を与える可能性があります。 SFCのデータプレーンプロトコル定義には、機密情報を処理するときに使用するために、パケットまたはSFPの粒度でそのような情報を保護するための適切な規定を含めることができます。同様に、SFCで使用される制御メカニズムには、そのようなメカニズムが使用可能であることを確認し、必要なときにそれらが使用されることを保証するための規定を含めることができます。これを実行できないと、適切な管理システムにエラーが表示される必要があります。特に、特定のサービスチェーンの特定のポイントでパケットに機密情報が追加される可能性があることを制御システムが知っている場合、制御メカニズムは、情報が追加されたポイントからNSH情報の適切な保護処理が利用可能であることを確認する必要があります。削除される場所。そのようなメカニズムが利用できない場合、エラー通知が生成されるべきです（SHOULD）。
Additionally, SFC OAM functions need to not negatively affect the security considerations of an SFC-enabled domain.
さらに、SFC OAM機能は、SFC対応ドメインのセキュリティに関する考慮事項に悪影響を及ぼさないようにする必要があります。
Finally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed, poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network.
最後に、サービスチェーンメカニズムとやり取りするすべてのエンティティ（ソフトウェアまたはハードウェア）は、不正な形式の不適切に構成された（意図的であるかどうかにかかわらず）プロトコルコンストラクトおよびループに対するセキュリティ手段を提供する必要があります。これらの考慮事項は、ネットワーク、特にオーバーレイネットワークの場合とほぼ同じです。
[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>。
[Boucadair2014] Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Guichard, J., and C. Pignataro, "Service Function Chaining: Framework & Architecture", Work in Progress, draft-boucadair-sfc-framework-02, February 2014.
[Boucadair2014] Boucadair、M.、Jacquenet、C.、Parker、R.、Lopez、D.、Guichard、J.、and C. Pignataro、 "Service Function Chaining：Framework＆Architecture"、Work in Progress、draft-boucadair -sfc-framework-02、2014年2月。
[Quinn2014] Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Architecture", Work in Progress, draft-quinn-sfc-arch-05, May 2014.
[Quinn2014] Quinn、P。およびJ. Halpern、「Service Function Chaining（SFC）Architecture」、Work in Progress、draft-quinn-sfc-arch-05、2014年5月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296 >。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <http://www.rfc-editor.org/info/rfc7498>.
[RFC7498]クイン、P。、エド。 T.ナドー編、「サービス機能連鎖の問題ステートメント」、RFC 7498、DOI 10.17487 / RFC7498、2015年4月、<http://www.rfc-editor.org/info/rfc7498>。
Acknowledgments
謝辞
The editors would like to thank Sam Aldrin, Alia Atlas, Nicolas Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, Chris Inacio, Nagendra Kumar, Hongyu Li, Andrew Malis, Guy Meador III, Kengo Naito, Thomas Narten, Ron Parker, Reinaldo Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong for a thorough review and useful comments.
編集者は、Sam Aldrin、Alia Atlas、Nicolas Bouthors、Stewart Bryant、Linda Dunbar、Alla Goldner、Ken Grey、Barry Greene、Anil Gunturu、David Harrington、Shunsuke Homma、Dave Hood、Chris Inacio、Nagendra Kumar、Hongyu Liに感謝します。 、Andrew Malis、Guy Meador III、内藤健吾、Thomas Narten、Ron Parker、Reinaldo Penno、Naiming Shen、Xiaohu Xu、Lucy Yongによる徹底的なレビューと有益なコメント。
The initial draft of this document was the result of merging two previous documents, and this section lists the acknowledgments from those documents.
このドキュメントの最初のドラフトは、2つの以前のドキュメントをマージした結果であり、このセクションでは、これらのドキュメントからの謝辞を示します。
From "Service Function Chaining (SFC) Architecture" [Quinn2014]
「Service Function Chaining（SFC）アーキテクチャ」より[Quinn2014]
The authors would like to thank David Ward, Abhijit Patra, Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong, and Christian Jacquenet for their review and comments.
著者のレビューとコメントを提供してくれたDavid Ward、Abhijit Patra、Nagaraj Bagepalli、Darrel Lewis、Ron Parker、Lucy Yong、およびChristian Jacquenetに感謝します。
From "Service Function Chaining (SF) - Framework and Architecture" [Boucadair2014]:
「Service Function Chaining（SF）-Framework and Architecture」[Boucadair2014]から：
Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R. White, and B. Chatras for their review and comments.
D. Abgrall、D。Minodier、Y。Le Goff、D。Cheng、R。White、およびB. Chatrasのレビューとコメントに感謝します。
Contributors
貢献者
As noted above, this document is the result of merging two previous documents. This section lists those who provided important ideas and text that fed into this architecture.
上記のように、このドキュメントは以前の2つのドキュメントをマージした結果です。このセクションでは、このアーキテクチャに取り入れられた重要なアイデアとテキストを提供した人をリストします。
The authors of "Service Function Chaining (SFC) - Framework and Architecture" [Boucadair2014] were:
「Service Function Chaining（SFC）-Framework and Architecture」[Boucadair2014]の著者は次のとおりです。
Mohamed Boucadair Christian Jacquenet Ron Parker Diego R. Lopez Jim Guichard Carlos Pignataro
モハメドブーカデールクリスチャンジャックネットロンパーカーディエゴRロペスジムギチャードカルロスピニャタロ
The contributors were:
貢献者は：
Parviz Yegani Paul Quinn Linda Dunbar
Parviz Yeganiポールクインリンダダンバー
The authors of "Service Function Chaining (SFC) Architecture" [Quinn2014] were:
「Service Function Chaining（SFC）Architecture」[Quinn2014]の著者は次のとおりです。
Paul Quinn (editor) Joel Halpern (editor)
ポール・クイン（編集者）ジョエル・ハルパーン（編集者）
The contributors were:
貢献者は：
Puneet Agarwal Andre Beliveau Kevin Glavin Ken Gray Jim Guichard Surendra Kumar Darrel Lewis Nic Leymann Rajeev Manur Thomas Nadeau Carlos Pignataro Michael Smith Navindra Yadav
プニートアガルワルアンドレベリボーケビングラビンケングレイジムギチャードスレンドラクマールダレルルイスニックレイマンラジーブマヌールトーマスナドーカルロスピニャタロマイケルスミスナヴィンドラヤダブ
Authors' Addresses
著者のアドレス
Joel Halpern (editor) Ericsson
ジョエル・ハルパーン（編集者）エリクソン
Email: jmh@joelhalpern.com
Carlos Pignataro (editor) Cisco Systems, Inc.
Carlos Pignataro（編集者）Cisco Systems、Inc.
Email: cpignata@cisco.com