[要約] RFC 7498は、サービス機能チェイニングの問題を明確にし、解決策を提案するためのものです。その目的は、ネットワークサービスの効率的な提供と管理を実現することです。
Internet Engineering Task Force (IETF) P. Quinn, Ed.
Request for Comments: 7498 Cisco Systems, Inc.
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
April 2015
Problem Statement for Service Function Chaining
サービス機能連鎖の問題ステートメント
Abstract
概要
This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.
このドキュメントでは、大規模な環境でのサービス機能（ファイアウォール、ロードバランサーなど）の展開に関連する問題の概要について説明します。 「サービス機能の連鎖」という用語は、そのようなサービス機能のインスタンスの順序付きリストの定義とインスタンス化、およびそれらのサービス機能を通過するトラフィックフローの後続の「ステアリング」を説明するために使用されます。
The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.
有効なサービス機能チェーンのセットは、オペレーターサービスの提供を反映し、アプリケーションの配信とサービスおよびネットワークポリシーと組み合わせて設計されています。
This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.
このドキュメントは、Service Function Chaining（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/rfc7498.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7498で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Topological Dependencies . . . . . . . . . . . . . . . . 5
2.2. Configuration Complexity . . . . . . . . . . . . . . . . 6
2.3. Constrained High Availability . . . . . . . . . . . . . . 6
2.4. Consistent Ordering of Service Functions . . . . . . . . 6
2.5. Application of Service Policy . . . . . . . . . . . . . . 6
2.6. Transport Dependence . . . . . . . . . . . . . . . . . . 7
2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . 7
2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . 7
2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7
2.10. Classification/Reclassification per Service Function . . 7
2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8
2.12. Multi-vendor Service Functions . . . . . . . . . . . . . 8
3. Service Function Chaining . . . . . . . . . . . . . . . . . . 8
3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 8
3.2. Service Classification . . . . . . . . . . . . . . . . . 9
3.3. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The delivery of end-to-end services often requires various service functions including traditional network service functions (for example, firewalls and server load balancers), as well as application-specific features such as HTTP header manipulation. Service functions may be delivered within the context of an isolated user (e.g., a tenant) or shared amongst many users or user groups.
エンドツーエンドサービスの配信では、多くの場合、従来のネットワークサービス機能（ファイアウォールやサーバーロードバランサーなど）を含むさまざまなサービス機能、およびHTTPヘッダー操作などのアプリケーション固有の機能が必要です。サービス機能は、隔離されたユーザー（例：テナント）のコンテキスト内で提供されるか、または多くのユーザーまたはユーザーグループ間で共有されます。
Current deployment models for service functions are often tightly coupled to network topology and physical resources, thus resulting in relatively rigid and static deployments. The static nature of such deployments greatly reduces and, in many cases, limits the ability of an operator to introduce new or modify existing services and/or service functions. Furthermore there is a cascading effect: changing one or more elements of a service function chain often affects other elements in the chain and/or the network elements used to construct the chain.
サービス機能の現在の展開モデルは、多くの場合、ネットワークトポロジと物理リソースに密接に結合されているため、比較的固定された静的な展開になります。このような展開の静的な性質により、オペレーターが新しいサービスを導入したり、既存のサービスやサービス機能を変更したりする能力が大幅に低下し、多くの場合は制限されます。さらに、連鎖的な影響があります。サービス機能チェーンの1つ以上の要素を変更すると、チェーン内の他の要素や、チェーンの構築に使用されるネットワーク要素に影響が及ぶことがよくあります。
This issue is particular acute in elastic service environments that require relatively rapid creation, destruction, or movement of physical or virtual service functions or network elements. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic and very granular service delivery, post facto modification, and the movement of service functions and application workloads in the existing network. The service insertion model must also retain the network and service policies and the ability to easily bind service policy to granular information such as per-subscriber state.
この問題は、物理または仮想サービス機能またはネットワーク要素の比較的迅速な作成、破棄、または移動を必要とする弾性サービス環境で特に深刻です。さらに、仮想プラットフォームへの移行には、柔軟で非常に細かいサービスの提供、事後の変更、および既存のネットワークでのサービス機能とアプリケーションワークロードの移動をサポートする俊敏なサービス挿入モデルが必要です。サービス挿入モデルは、ネットワークポリシーとサービスポリシー、およびサービスポリシーを加入者ごとの状態などの詳細な情報に簡単にバインドする機能も保持する必要があります。
This document outlines the problems encountered with existing service deployment models for Service Function Chaining (SFC), which is often referred to simply as "service chaining" (in this document, the terms will be used interchangeably). Section 3 of this document highlights three key areas of WG focus for investigating solutions that address the current problems. The document highlights three key areas of WG focus for addressing the issues highlighted in this document that will form the basis for the possible WG solutions that address the current problems.
このドキュメントでは、サービス機能チェーン（SFC）の既存のサービス展開モデルで発生する問題について概説します。SFCは、単に「サービスチェーン」と呼ばれることがあります（このドキュメントでは、用語は同じ意味で使用されます）。この文書のセクション3は、現在の問題に対処するソリューションを調査するためのWGの焦点の3つの主要な領域を強調しています。このドキュメントは、現在の問題に対処する可能性のあるWGソリューションの基礎を形成する、このドキュメントで強調された問題に対処するためのWGの3つの重要な領域を強調しています。
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, or service specific.
分類：必要なネットワークサービス機能のセットを後で適用するために、ポリシーに対してトラフィックフローをローカルにインスタンス化して照合します。ポリシーは、顧客、ネットワーク、またはサービスに固有の場合があります。
Network Overlay: A logical network built, via virtual links or packet encapsulation, over an existing network (the underlay).
ネットワークオーバーレイ：既存のネットワーク（アンダーレイ）上に仮想リンクまたはパケットカプセル化を介して構築された論理ネットワーク。
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.
注：このドキュメント以外では、「サービス」という用語はさまざまな定義で過負荷になっています。たとえば、一部のサービスは事業者のネットワーク内のいくつかの要素で構成されるオファリングですが、他のサービス、具体的にはネットワークサービスはファイアウォールなどの個別の要素です。従来、このようなサービスは（後者の意味で）一連のサービス機能をホストし、サービスがホストされるネットワークロケーターを備えています。
Service Function: 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.
サービス機能：受信したパケットの特定の処理を担当する機能。サービス機能は、プロトコルスタックのさまざまなレイヤー（ネットワークレイヤーや他のOSIレイヤーなど）で機能します。論理コンポーネントとして、サービス機能は仮想要素として実現するか、物理ネットワーク要素に組み込むことができます。 1つ以上のサービス機能を同じネットワーク要素に組み込むことができます。同じ管理ドメインにサービス機能の複数のオカレンスが存在する可能性があります。
A non-exhaustive list of service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.
サービス機能の完全なリストには、ファイアウォール、WANおよびアプリケーションアクセラレーション、ディープパケットインスペクション（DPI）、サーバーロードバランサー、NAT44 [RFC3022]、NAT64 [RFC6146]、HTTPヘッダーエンリッチメント機能、およびTCPオプティマイザーが含まれます。
The generic term "L4-L7 services" is often used to describe many service functions.
「L4-L7サービス」という総称は、多くのサービス機能を表すためによく使用されます。
Service Function Chain (SFC): A service function chain defines an ordered or partially ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets, 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）：サービス機能チェーンは、順序付けまたは部分的に順序付けされた抽象サービス機能（SF）のセットと、分類の結果として選択されたパケット、フレーム、フローに適用する必要がある順序付け制約を定義します。抽象サービス機能の例はファイアウォールです。アーキテクチャは複数のブランチにコピーするSFCを許可し、サービス機能を適用する必要がある順序に柔軟性がある場合も許可するため、暗黙の順序は線形進行ではない場合があります。 「サービスチェーン」という用語は、「サービス機能チェーン」の省略形としてよく使用されます。
Service Overlay: An overlay network created for the purpose of forwarding data to required service functions.
サービスオーバーレイ：必要なサービス機能にデータを転送する目的で作成されたオーバーレイネットワーク。
Service Topology: The service overlay connectivity forms a service topology.
サービストポロジ：サービスオーバーレイ接続は、サービストポロジを形成します。
The following points describe aspects of existing service deployments that are problematic and that the SFC working group aims to address.
次のポイントは、問題があり、SFCワーキンググループが対処することを目的としている既存のサービス展開の側面について説明しています。
Network service deployments are often coupled to network topology, whether it be physical, virtualized, or a hybrid of the two. For example, use of a firewall requires that traffic flow through the firewall, which means placing the firewall on the network path (often via creation of VLANs) or architecting the network topology to steer traffic through the firewall. Such dependency imposes constraints on service delivery, potentially inhibiting the network operator from optimally utilizing service resources, and reduces flexibility. This limits scale, capacity, and redundancy across network resources.
ネットワークサービスの展開は、物理、仮想、またはその2つのハイブリッドのいずれであっても、多くの場合、ネットワークトポロジに結合されます。たとえば、ファイアウォールを使用するには、トラフィックがファイアウォールを通過する必要があります。つまり、ファイアウォールをネットワークパスに配置する（多くの場合、VLANを作成する）か、ネットワークトポロジを構築してトラフィックをファイアウォールに誘導します。このような依存関係は、サービス配信に制約を課し、ネットワークオペレーターがサービスリソースを最適に利用できなくなる可能性があり、柔軟性が低下します。これにより、ネットワークリソース全体の規模、容量、冗長性が制限されます。
These topologies serve only to "insert" the service function (i.e., ensure that traffic traverses a service function); they are not required from a native packet delivery perspective. For example, firewalls often require an "in" and "out" Layer 2 segment and adding a new firewall requires changing the topology (i.e., adding new Layer 2 segments and/or IP subnets).
これらのトポロジは、サービス機能を「挿入」するためにのみ機能します（つまり、トラフィックがサービス機能を通過するようにします）。ネイティブのパケット配信の観点からは必要ありません。たとえば、ファイアウォールは「イン」および「アウト」のレイヤー2セグメントを必要とすることが多く、新しいファイアウォールを追加するにはトポロジを変更する必要があります（つまり、新しいレイヤー2セグメントやIPサブネットを追加する必要があります）。
As more service functions are required -- often with strict ordering -- topology changes are needed in "front" and "behind" each service function, resulting in complex network changes and device configuration. In such topologies, all traffic, whether a service function needs to be applied or not, often passes through the same strict order.
より多くのサービス機能が必要になると（多くの場合、厳密な順序付けで）、トポロジーの変更が各サービス機能の「前」と「後ろ」で必要となり、複雑なネットワーク変更とデバイス構成が発生します。このようなトポロジでは、サービス機能を適用する必要があるかどうかに関係なく、すべてのトラフィックが同じ厳密な順序で通過することがよくあります。
The topological coupling limits placement and selection of service functions: service functions are "fixed" in place by topology. Therefore, placement and service function selection that take into account network topology information such as load, new links, or traffic engineering are often not possible.
トポロジー結合は、サービス機能の配置と選択を制限します。サービス機能はトポロジーによって「固定」されます。したがって、負荷、新しいリンク、トラフィックエンジニアリングなどのネットワークトポロジ情報を考慮した配置とサービス機能の選択は、多くの場合不可能です。
A common example is web servers using a server load balancer as the default gateway. When the web service responds to non-load-balanced traffic (e.g., administrative or backup operations), all traffic from the server must traverse the load balancer, forcing network administrators to create complex routing schemes or additional interfaces to provide an alternate topology.
一般的な例は、サーバーロードバランサーをデフォルトゲートウェイとして使用するWebサーバーです。 Webサービスが負荷分散されていないトラフィック（管理またはバックアップ操作など）に応答する場合、サーバーからのすべてのトラフィックはロードバランサーを通過する必要があり、ネットワーク管理者は複雑なルーティングスキームまたは追加のインターフェースを作成して代替トポロジを提供する必要があります。
A direct consequence of topological dependencies is the complexity of the entire configuration, specifically in deploying service function chains. Simple actions such as changing the order of the service functions in a service function chain require changes to the logical and/or physical topology. However, network operators are hesitant to make changes to the network once services are installed, configured, and deployed in production environments for fear of misconfiguration and consequent downtime. All of this leads to very static service delivery deployments. Furthermore, the speed at which these topological changes can be made is not rapid or dynamic enough, as it often requires manual intervention or use of slow provisioning systems.
トポロジーの依存関係の直接的な結果は、特にサービス機能チェーンのデプロイにおける構成全体の複雑さです。サービス機能チェーン内のサービス機能の順序を変更するなどの単純なアクションでは、論理トポロジーおよび/または物理トポロジーを変更する必要があります。ただし、ネットワークオペレーターは、サービスのインストール、構成、および展開がいったん本番環境に行われると、誤った構成とその結果としてのダウンタイムを恐れて、ネットワークに変更を加えることをためらっています。これらすべてが、非常に静的なサービス提供の展開につながります。さらに、これらのトポロジーの変更を行う速度は、手動による介入や遅いプロビジョニングシステムの使用を必要とする場合が多いため、十分に高速または動的ではありません。
Since traffic reaches many service functions based on network topology, alternate or redundant service functions must be placed in the same topology as the primary service.
トラフィックはネットワークトポロジに基づいて多くのサービス機能に到達するため、代替サービスまたは冗長サービス機能をプライマリサービスと同じトポロジに配置する必要があります。
An effect of topological dependency is that the availability of service functions is constrained.
トポロジー依存の影響は、サービス機能の可用性が制限されることです。
Service functions are typically independent; service function_1 (SF1)...service function_n (SFn) are unrelated, and there is no notion at the service layer that SF1 occurs before SF2. However, to an administrator, many service functions have a strict ordering that must be in place, yet the administrator has no consistent way to impose and verify the ordering of the service functions that are used to deliver a given service. Furthermore, altering the order of a deployed chain is complex and cumbersome.
通常、サービス機能は独立しています。 service function_1（SF1）... service function_n（SFn）は無関係であり、SF2の前にSF1が発生するというサービス層の概念はありません。ただし、管理者にとって、多くのサービス機能には厳密な順序を設定する必要がありますが、管理者は特定のサービスの提供に使用されるサービス機能の順序を強制および確認する一貫した方法がありません。さらに、デプロイされたチェーンの順序を変更することは複雑で面倒です。
Service functions rely on topology information such as VLANs or packet classification/reclassification to determine service policy selection, i.e., the service function specific action taken. Topology information is increasingly less viable due to scaling, tenancy, and complexity reasons. Topology-centric information often does not convey adequate information to the service functions, forcing functions to individually perform more granular classification. In other words, the topology information is not granular enough, and its semantics is often overloaded.
サービス機能は、VLANやパケットの分類/再分類などのトポロジー情報に基づいて、サービスポリシーの選択、つまり、実行されるサービス機能固有のアクションを決定します。トポロジー情報は、スケーリング、テナンシー、および複雑さの理由により、実行可能性がますます低くなっています。トポロジー中心の情報は、多くの場合、適切な情報をサービス機能に伝達せず、機能に個別に、より詳細な分類を強制します。つまり、トポロジ情報は十分に細分性が低く、そのセマンティクスが過負荷になることがよくあります。
Service functions can and will be deployed in networks with a range of network transports, including network under and overlays, such as Ethernet, Generic Routing Encapsulation (GRE), Virtual eXtensible Local Area Network (VXLAN), MPLS, etc. The coupling of service functions to topology may require service functions to support many transport encapsulations or for a transport gateway function to be present.
サービス機能は、イーサネット、Generic Routing Encapsulation（GRE）、Virtual eXtensible Local Area Network（VXLAN）、MPLSなどのネットワークアンダーおよびオーバーレイを含む、さまざまなネットワークトランスポートを備えたネットワークに展開できます。また、展開されます。サービスの結合トポロジへの機能では、多くのトランスポートカプセル化をサポートするため、またはトランスポートゲートウェイ機能が存在するために、サービス機能が必要になる場合があります。
Given that the current state of the art for adding/removing service functions largely centers around VLANs and routing changes, rapid changes to the deployed service capacity (increasing or decreasing) can be hard to realize due to the risk and complexity of VLANs and/or routing modifications.
サービス機能を追加/削除するための現在の最新技術は主にVLANとルーティングの変更に集中しているため、展開されたサービスキャパシティの急速な変更（増加または減少）は、VLANおよび/またはルーティングの変更。
Traffic selection is coarse; that is, all traffic on a particular segment traverses all service functions whether or not the traffic requires service enforcement. This lack of traffic selection is largely due to the topological nature of service deployment since the forwarding topology dictates how (and what) data traverses which service function(s). In some deployments, more granular traffic selection is achieved using policy routing or access control filtering. This results in operationally complex configurations and is still relatively coarse and inflexible.
トラフィックの選択は粗雑です。つまり、特定のセグメント上のすべてのトラフィックは、トラフィックがサービス実施を必要とするかどうかに関係なく、すべてのサービス機能を通過します。このトラフィック選択の欠如は、転送トポロジがデータがどのサービス機能をどのように（そして何を）トラバースするかを決定するため、主にサービス展開のトポロジー的な性質によるものです。一部の展開では、ポリシールーティングまたはアクセスコントロールフィルタリングを使用して、より詳細なトラフィックを選択できます。これは、運用上複雑な構成をもたらし、依然として比較的粗く、柔軟性がありません。
Troubleshooting service-related issues is a complex process that involves both network-specific and service-specific expertise. This is especially the case when service function chains span multiple data centers or cross administrative boundaries. Furthermore, the physical and virtual environments (network and service) can be highly divergent in terms of topology, and that topological variance adds to these challenges.
サービス関連の問題のトラブルシューティングは、ネットワーク固有の専門知識とサービス固有の専門知識の両方が関与する複雑なプロセスです。これは、サービス機能チェーンが複数のデータセンターにまたがる場合や、管理境界を越える場合に特に当てはまります。さらに、物理環境と仮想環境（ネットワークとサービス）はトポロジーの点で大きく異なる可能性があり、そのトポロジーの違いがこれらの課題に追加されます。
Classification occurs at each service function, independent from previously applied service functions since there are limited mechanisms to share the detailed classification information between services. The classification functionality often differs between service functions, and service functions may not leverage the classification results from other service functions.
サービス間で詳細な分類情報を共有するメカニズムは限られているため、以前に適用されたサービス機能とは関係なく、分類は各サービス機能で行われます。多くの場合、分類機能はサービス機能間で異なり、サービス機能は他のサービス機能からの分類結果を活用しない場合があります。
Service function chains may be unidirectional or bidirectional depending on the state requirements of the service functions. In a unidirectional chain, traffic is passed through a set of service functions in one forwarding direction only. Bidirectional chains require traffic to be passed through a set of service functions in both forwarding directions. Many common service functions such as DPI and firewalls often require bidirectional chaining in order to ensure flow state is consistent.
サービス関数チェーンは、サービス関数の状態要件に応じて、単方向または双方向の場合があります。単方向チェーンでは、トラフィックは1つの転送方向でのみ一連のサービス機能を通過します。双方向チェーンでは、トラフィックは、転送方向の両方で一連のサービス機能を通過する必要があります。 DPIやファイアウォールなどの多くの一般的なサービス機能では、フロー状態の一貫性を確保するために双方向チェーンが必要になることがよくあります。
Existing service deployment models provide a static approach to realizing forward and reverse associations of service function chains, most often requiring complex configuration of each network device throughout the SFC. In other words, the same complex network configuration must be in place for both "directions" of the traffic, effectively doubling the configuration and associated testing. Further, if partial symmetry is required (i.e., only some of the services in the chain required symmetry), the network configuration complexity increases since the operator must ensure that the exceptions -- the services that do not need the symmetry flow -- are handled correctly via unique configuration to account for their requirements.
既存のサービス展開モデルは、サービス機能チェーンの順方向および逆方向の関連付けを実現するための静的なアプローチを提供します。ほとんどの場合、SFC全体で各ネットワークデバイスの複雑な構成が必要です。つまり、トラフィックの両方の「方向」に同じ複雑なネットワーク構成を配置して、構成と関連するテストを効果的に2倍にする必要があります。さらに、部分的な対称性が必要な場合（つまり、対称性が必要なチェーンの一部のサービスのみ）、オペレーターは例外（対称性フローを必要としないサービス）を確実に処理する必要があるため、ネットワーク構成の複雑さが増します。固有の構成を介して正しくそれらの要件を説明します。
Deploying service functions from multiple vendors often requires per-vendor expertise (insertion models differ, common attributes are few, and inter-vendor service functions do not share information), hence standards are needed to ensure interoperability.
複数のベンダーのサービス機能を導入するには、ベンダーごとの専門知識が必要な場合が多く（挿入モデルが異なり、共通の属性が少なく、ベンダー間サービス機能が情報を共有しないため）、相互運用性を確保するための標準が必要です。
Service function chaining aims to address the aforementioned problems associated with service deployment. Concretely, the SFC working group will investigate solutions that address the following elements.
サービス機能の連鎖は、サービスの展開に関連する前述の問題に対処することを目的としています。具体的には、SFCワーキンググループは、以下の要素に対処するソリューションを調査します。
Service function chaining utilizes a service-specific overlay that creates the service topology. The service overlay provides service function connectivity, built "on top" of the existing network topology. It allows operators to use whatever overlay or underlay they prefer to create a path between service functions and to locate service functions in the network as needed.
サービス関数チェーンは、サービストポロジを作成するサービス固有のオーバーレイを利用します。サービスオーバーレイは、既存のネットワークトポロジの「上」に構築されたサービス機能接続を提供します。これにより、オペレーターは、サービス機能間のパスを作成し、必要に応じてネットワーク内のサービス機能を見つけるために、好みのオーバーレイまたはアンダーレイを使用できます。
Within the service topology, service functions can be viewed as resources for consumption and an arbitrary topology constructed to connect those resources in a required order. Adding new service functions to the topology is easily accomplished, and no underlying network changes are required.
サービストポロジ内では、サービス機能は消費用のリソースと見なすことができ、それらのリソースを必要な順序で接続するように構築された任意のトポロジと見なすことができます。トポロジに新しいサービス機能を追加するのは簡単で、基盤となるネットワークの変更は必要ありません。
Lastly, the service overlay can provide service-specific information needed for troubleshooting service-related issues.
最後に、サービスオーバーレイは、サービス関連の問題のトラブルシューティングに必要なサービス固有の情報を提供できます。
Classification is used to select which traffic enters a service overlay. The granularity of the classification varies based on device capabilities, customer requirements, and services offered. Initial classification determines the service function chain required to process the traffic. Subsequent classification can be used within a given service function chain to alter the sequence of service functions applied. Symmetric classification ensures that forward and reverse chains are in place. Similarly, asymmetric -- relative to required service function -- chains can be achieved via service classification.
分類は、サービスオーバーレイに入るトラフィックを選択するために使用されます。分類の細分性は、デバイスの機能、顧客の要件、および提供されるサービスによって異なります。最初の分類により、トラフィックの処理に必要なサービス機能チェーンが決まります。特定のサービス機能チェーン内で後続の分類を使用して、適用されるサービス機能のシーケンスを変更できます。対称分類により、順方向チェーンと逆方向チェーンが適切に配置されます。同様に、非対称-必要なサービス機能に対して-チェーンは、サービス分類を介して実現できます。
The SFC encapsulation enables the creation of a service chain in the data plane and can convey information about the chain such as chain identification and OAM status.
SFCカプセル化により、データプレーンでのサービスチェーンの作成が可能になり、チェーン識別やOAMステータスなどのチェーンに関する情報を伝達できます。
The SFC encapsulation also carries data-plane metadata that provides the ability to exchange information between logical classification points and service functions (and vice versa) and between service functions. Metadata is not used as forwarding information to deliver packets along the service overlay.
SFCカプセル化には、論理分類ポイントとサービス機能間（およびその逆）の間、およびサービス機能間で情報を交換する機能を提供するデータプレーンメタデータも含まれます。メタデータは、サービスオーバーレイに沿ってパケットを配信するための転送情報として使用されません。
Metadata can include the result of antecedent classification and/or information from external sources. Service functions utilize metadata, as required, for localized policy decisions.
メタデータには、先行分類の結果や外部ソースからの情報を含めることができます。サービス機能は、ローカライズされたポリシー決定のために、必要に応じてメタデータを利用します。
In addition to sharing of information, the use of metadata addresses several of the issues raised in Section 2, most notably by decoupling policy from the network topology, and by removing the need for classification (and reclassification) per service function as described in Section 2.10.
メタデータを使用すると、情報の共有に加えて、セクション2で発生したいくつかの問題に対処できます。特に、ポリシーをネットワークトポロジから切り離し、セクション2.10で説明されているように、サービス機能ごとに分類（および再分類）する必要をなくすことで解決します。 。
A common approach to service metadata creates a foundation for interoperability between service functions, regardless of vendor.
サービスメタデータへの共通のアプローチは、ベンダーに関係なく、サービス機能間の相互運用性の基盤を作成します。
Although this problem statement does not introduce any protocols, when considering service function chaining, the three main areas begin investigated (see Section 3) by the WG have security aspects that warrant consideration.
この問題の説明ではプロトコルを紹介していませんが、サービス機能の連鎖を検討する場合、WGが調査を開始する3つの主要な領域（セクション3を参照）には、検討が必要なセキュリティ面があります。
Service Overlay: The service overlay will be constructed using existing transport protocols (e.g., MPLS, VXLAN) and as such is subject to the security specifics of the transport selected. If an operator requires authenticity and/or confidentiality in the service overlay, a transport (e.g., IPsec) that provides such functionally can be used.
サービスオーバーレイ：サービスオーバーレイは、既存のトランスポートプロトコル（MPLS、VXLANなど）を使用して構築されるため、選択したトランスポートのセキュリティ仕様に依存します。オペレーターがサービスオーバーレイで信頼性や機密性を必要とする場合は、そのような機能を提供するトランスポート（IPsecなど）を使用できます。
Classification: Since classification is used to select the appropriate service overlay and the required service encapsulation details, classification policy must be both accurate and trusted. Conveying the policy to an SFC edge node (a node that forms the logical boundary of an SFC domain) may be done via a multitude of methods depending on an operator's existing provisioning practices and security posture.
分類：分類は適切なサービスオーバーレイと必要なサービスカプセル化の詳細を選択するために使用されるため、分類ポリシーは正確で信頼できるものである必要があります。 SFCエッジノード（SFCドメインの論理境界を形成するノード）へのポリシーの伝達は、オペレーターの既存のプロビジョニング方法とセキュリティ体制に応じて、さまざまな方法で行うことができます。
Additionally, traffic entering the SFC domain and being classified may be encrypted, thus limiting the granularity of classification. The use of pervasive encryption varies based on type of traffic, environment, and level of operator control. For instance, a large enterprise can mandate how encryption is used by its users, whereas a broadband provider likely does not have the ability to do so.
さらに、SFCドメインに入って分類されるトラフィックは暗号化される可能性があるため、分類の粒度が制限されます。広範な暗号化の使用は、トラフィックのタイプ、環境、およびオペレーター制御のレベルによって異なります。たとえば、大企業は、ユーザーによる暗号化の使用方法を義務付けることができますが、ブロードバンドプロバイダーは、そうすることができない可能性があります。
The use of encrypted traffic, however, does not obviate the need for SFC (nor the problems associated with current deployment models described herein); rather, when encrypted traffic must be classified, the granularity of such classification must adapt. In such cases, service overlay selection might occur using outer (i.e., unencrypted) header information (in the presence of encryption) or external information about the packets.
ただし、暗号化されたトラフィックを使用しても、SFCの必要性（およびここで説明する現在の展開モデルに関連する問題）は解消されません。むしろ、暗号化されたトラフィックを分類する必要がある場合、そのような分類の細分性を適応させる必要があります。このような場合、サービスオーバーレイの選択は、外部（つまり、暗号化されていない）ヘッダー情報（暗号化が存在する場合）またはパケットに関する外部情報を使用して行われる可能性があります。
SFC Encapsulation: As described in Section 3, the SFC encapsulation carries information about the SFC and data-plane metadata. Depending on the environment and security posture, the SFC encapsulation might need to be authenticated and/or encrypted. The use of an appropriate overlay transport (as described above) can provide data-plane confidentiality and authenticity.
SFCカプセル化：セクション3で説明したように、SFCカプセル化はSFCおよびデータプレーンメタデータに関する情報を伝達します。環境とセキュリティ体制によっては、SFCカプセル化を認証または暗号化する必要がある場合があります。 （上記のように）適切なオーバーレイトランスポートを使用すると、データプレーンの機密性と信頼性を提供できます。
The exchange of SFC encapsulation data such as metadata must originate from trusted source(s). Also, if needed, authentication and confidentiality protection should be provided during the exchange to the various SFC nodes.
メタデータなどのSFCカプセル化データの交換は、信頼できるソースから行う必要があります。また、必要に応じて、さまざまなSFCノードとの交換中に認証と機密保護を提供する必要があります。
SFC and Multi-tenancy: If tenant isolation is required in an SFC deployment, an appropriate network transport overlay that provides adequate isolation and identification can be used. Additionally, tenancy might be used in the selection of the appropriate service chain; however, as stated, the network overlay is still required to provide transport isolation. SF deployment and how specific SFs might or might not be allocated per tenant are outside the scope of this document.
SFCとマルチテナント：SFC展開でテナントの分離が必要な場合は、適切な分離と識別を提供する適切なネットワークトランスポートオーバーレイを使用できます。さらに、適切なサービスチェーンの選択にテナンシーを使用できます。ただし、前述のように、トランスポートを分離するには、ネットワークオーバーレイが依然として必要です。 SFの展開と、テナントごとに特定のSFを割り当てる方法と割り当てない方法は、このドキュメントの範囲外です。
The SFC Architecture document [SFC-ARCH] presents a more complete review of the security implications of a complete SFC architecture.
SFCアーキテクチャドキュメント[SFC-ARCH]は、完全なSFCアーキテクチャのセキュリティへの影響に関するより完全なレビューを提供します。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、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, 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、2011年4月、<http：//www.rfc -editor.org/info/rfc6146>。
[SFC-ARCH] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", Work in Progress, draft-ietf-sfc-architecture-07, March 2015.
[SFC-ARCH] Halpern、J。およびC. Pignataro、「Service Function Chaining（SFC）Architecture」、Work in Progress、draft-ietf-sfc-architecture-07、2015年3月。
Acknowledgments
謝辞
The authors would like to thank David Ward, Rex Fernando, David McDysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel Halpern, and Jim French for their reviews and comments.
著者は、レビューとコメントを提供してくれたDavid Ward、Rex Fernando、David McDysan、Jamal Hadi Salim、Charles Perkins、Andre Beliveau、Joel Halpern、およびJim Frenchに感謝します。
Additionally, the authors would like to thank the IESG and Benjamin Kaduk for their detailed reviews and suggestions.
さらに、著者は、詳細なレビューと提案を提供してくれたIESGとBenjamin Kadukに感謝します。
Contributors
貢献者
The following people are active contributors to this document and have provided review, content and concepts (listed alphabetically by surname):
次の人々は、このドキュメントへの積極的な貢献者であり、レビュー、コンテンツ、および概念（姓のアルファベット順）を提供しています。
Puneet Agarwal Broadcom EMail: pagarwal@broadcom.com
Puneet Agarwal Broadcom Eメール：pagarwal@broadcom.com
Mohamed Boucadair France Telecom EMail: mohamed.boucadair@orange.com
Mohamed Boucadair France Telecom Eメール：mohamed.boucadair@orange.com
Abhishek Chauhan Citrix EMail: Abhishek.Chauhan@citrix.com
Abhishek Chauhan Citrix Eメール：Abhishek.Chauhan@citrix.com
Uri Elzur Intel EMail: uri.elzur@intel.com
Uri Elzur Intel EMail：uri.elzur@intel.com
Kevin Glavin Riverbed EMail: Kevin.Glavin@riverbed.com
Kevin Glavin Riverbed Eメール：Kevin.Glavin@riverbed.com
Ken Gray Cisco Systems EMail: kegray@cisco.com
ケングレイCisco Systems EMail：kegray@cisco.com
Jim Guichard Cisco Systems EMail:jguichar@cisco.com
ジムギチャードCisco Systems EMail：jguichar@cisco.com
Christian Jacquenet France Telecom EMail: christian.jacquenet@orange.com
Christian Jacquenet France Telecom Eメール：christian.jacquenet@orange.com
Surendra Kumar Cisco Systems EMail: smkumar@cisco.com
Surendra Kumar Cisco Systems EMail：smkumar@cisco.com
Nic Leymann Deutsche Telekom EMail: n.leymann@telekom.de Darrel Lewis Cisco Systems EMail: darlewis@cisco.com
Nic Leymann Deutsche Telekom Eメール：n.leymann@telekom.de Darrel LewisシスコシステムズEメール：darlewis@cisco.com
Rajeev Manur Broadcom EMail:rmanur@broadcom.com
Rajeev Manur Broadcom EMail：rmanur@broadcom.com
Brad McConnell Rackspace EMail: bmcconne@rackspace.com
Brad McConnell Rackspaceメール：bmcconne@rackspace.com
Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com
Carlos PignataroシスコシステムズEメール：cpignata@cisco.com
Michael Smith Cisco Systems EMail: michsmit@cisco.com
マイケルスミスシスコシステムズメール：michsmit@cisco.com
Navindra Yadav Cisco Systems EMail: nyadav@cisco.com
Navindra Yadavシスコシステムズメール：nyadava@scisco.com
Authors' Addresses
著者のアドレス
Paul Quinn (editor) Cisco Systems, Inc.
Paul Quinn（編集者）Cisco Systems、Inc.
EMail: paulq@cisco.com
Thomas Nadeau (editor) Brocade
Thomas Nadeau（編集者）Brocade
EMail: tnadeau@lucidvision.com